External Drives STILL ejecting during sleep in Ventura

I've posted here a number of times, with both questions and potential solutions, but until now nothing I've tried has worked, until... drum role; I've finally solved mine without any changes to default macOS settings. My eject drives problem has been with me from Mountain Lion up to and including High Sierra. Here is what has worked for me and why I believe it can be replicated.

First, have y'all noticed that Apple has never, and I mean never sold an Apple-branded USB hub? They now sell several third-party hubs but attach a disclaimer that all warranty or trouble claims must be submitted to the makers of those hubs. Translation in plain English; they know they have a problem with USB and the fix in either the firmware or the OS is not worth the dime to corporate Apple, especially since they have a story they can lay on you if you have a USB problem, to wit: SMC and/or NVRAM reset.

The problem I believe is a race condition between arrival of a wake up signal and the distribution and initialization of 5v dc over USB. It appears random because it is, because it cannot be duplicated: there is no way to resolve this to properly initialize 5v dc over USB without a significant engineering investment, and since Apple does not own USB, the way they do Firewire and Thunderbolt, why bother?

My problem was having two external drive enclosures on a 7-port USB hub. The hub was connected to a direct port on the machine. When the eject problem occurred, both of these drives always ejected, not just one but both, always both (actually 4, since both drives have 2 partitions.) Meanwhile, a RAID enclosure with its own power supply also connected to USB, but on the other direct USB port on my MBP, never ejected. I discussed this problem with technical support at both the hub and enclosure manufacturers and got conflicting advice. One said never put more than one enclosure on any hub, the other said never put even one enclosure on any hub even though they sell a 5v dc adapter for their enclosure. Their message; attach their enclosure with its own 5v dc source directly to the machine. Reading between the lines; this is subtle finger pointing, certainly implying the problem is Apple's. So I ran my own experiments.

First, I moved one of those drive enclosures to an open direct Firewire port. Voilà, this drive now never ejects while the one still on the hub did, at least once every 2 or 3 days. Remember, for me macOS has only default settings and sleep, if done correctly, is welcome. This is the only fair way to test macOS since it is valuable to permit drives to sleep on a system that is always on.

Next, I added a dedicated 5v dc power adapter to the drive enclosure. The hub itself has its own dedicated supply. Result, now neither of my two external drives eject. Going into my third week without a reboot and with no spurious ejects.

Conclusion: Apple has a latent bug in the hardware/firmware/software implementation of 5v over USB. Don't expect a solution anytime soon from Apple since we know the problem is present in all versions of macOS from at least Mountain Lion to Ventura, even in non-Intel machines given the comments on this site.

Hi,

Currently I have a homemade solution very lightweight and free:

• Install SleepWatcher: can use the official binary (link below) or recommended just install it with brew.

Link: https://www.bernhard-baehr.de/

With brew (the last one is to start the daemon with the system):

brew install sleepwatcher
brew services start sleepwatcher

As note, there is no need to grant input monitoring permissions to sleepwatcher for this.

• Create 2 scripts in the user folder that installed sleepwatcher with brew, if used the official binary, read its documentation:

.sleep

#!/bin/sh

for i in $(diskutil list external | grep external | awk '{print $1}'); do
	diskutil eject $i
done

.wakeup

#!/bin/sh

for i in $(diskutil list external | grep external | awk '{print $1}'); do
	diskutil mountDisk $i
done

Remember to set execute permission with 'chmod +x .sleep' and 'chmod +x .wakeup'.

And that's all on sleep it will eject all external drives, and on wakeup will mount them again.

Same issue here. I have spent more than 10 hours on the phone with apple to try and fix all the way upto tier 3 support. They go back to it must be all 20something drives I've tried and only and issue with the 1 computer i'm calling about. haha! Ridiculous. Same issue on 12 macs, and all sorts different drives, connection methods, os version and hardware. The mac pro's are by far the worst though.

It is not just a single eject it is an ongoing failed to eject, remounting, failed to eject and remount. This can happen a few hundred times over night. SSD's, HDD, thunderbolt, usb, firewire even. Powered drives, and usb bus powered.

What I've found so far is the same drives causing issue when connected through another powered medium wont have the issue. So my thunderbolt arrays connected via a thunderbolt display, or usb drive connected through a powered dock. A powersource between the mac and drive is required.

I've been experimenting with an app call ejectify which will force eject a drive when the display sleeps or computer sleeps. It works to eject but the mac is remounting then while sleeping and it'll fail to eject again. Disabling Powernap should prevent the remounting this but it doesn't work.

I respectfully disagree. While enabling that option 'fixes' the issue as it just doesn't prevent the computer for sleeping automatically, it doesn't really 'fix' it if one enables sleep mode manually (some of us do).

Conversely, as @Finest Planet reports, a different enclosure may very well provide a more solid 'fix'... luck permitting. It all depends on how the chipset implements the ACPI states. I've had that happen before, as I wrote in another post — this was several years ago on an Intel-based Mac (I can't recall which version of macOS), and I had to go through three different USB-SATA adapters before I found one that worked properly, incidentally by Verbatim. The others either exhibited this same behavior, or would continuously spin up and down while the iMac was sleeping.

Also, just recently, I had to return a TP-Link powered usb hub because it would hard reset when my new M2 Pro Mac Mini went to sleep. It has fancy lights on each of the ports, and no amount of fiddling with settings on the Mac would prevent all of them from brutally shutting down and then lighting up again. The same devices — especially a Toshiba 4 TB USB HDD which I always keep attached — work perfectly fine when connected to an old Anker powered hub. I put my Mac to sleep every night and never once have I woken up to an ejection warning with the Anker (and I did the same with the old iMac as well).

While Apple could probably do something better to handle this, the problem often lies in the way the sleep status is handled on the device. In theory, when the Mac goes to sleep, each device should switch to status D3Hot (sleep but powered), but many just drop to D3Cold (sleep and unpowered, i.e. unresponsive). At that point, it's as if one had tugged the drive out of the port, and the error appears. To exacerbate the problem, macOS tends to keep checking on devices, which leads to them being reconnected and disconnected multiple times over the course of a sleep session. Even when the device itself handles D3Hot properly, it's often woken up by the system — with an HDD that's easy to tell because it spins up. Some of it may also depend on which ACPI status the Mac goes into, which is not entirely clear (anything between S0ix and S3, I'd reckon.)

This has some basic info: https://en.wikipedia.org/wiki/ACPI#Power_states, and this page by Microsoft is quite enlightening: https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/device-sleeping-states. (Some of it is about Windows, but that's just because this is a manual about the the Windows kernel's internals.)

So while never going to sleep is a valid workaround at the expense of wasting power, a "proper" solution is using devices that implement sleep modes properly. It's impossible to know beforehand, though, which makes this issue very frustrating, especially as a single broken device in the chain (a hub, an adapter...) will screw everything up. It's why I haven't bitten the bullet on the Satechi stand hub — it looks great on paper and it's nice to have an NVMe SSD within it, but what if it ends up choking on sleep each night?

The 'prevent hard drives from sleeping' toggle in the system preferences is specifically designed for mechanical drives. SSD drives do not have mechanical components and thus are not impacted by this setting.

The SSD drives plugged into the USB ports on your system will be impacted because the USB ports deactivate when the computer goes to sleep. The ports are powered down, thus resulting in the 'disk not ejected properly' errors.

I discovered this over the weekend. I came back to find about 10 disk ejected errors on my screen. This means that the hub periodically got power (probably woke up for network wake) and then went back to sleep multiple times powering down the USB ports and then ejected the drive again.

This is NOT an issue of your computer, but the type of drive being used. However, Apple should include an option to not shut down USB ports or at least let us know if there is one with continuous power. I have to upload HUGE files that take hours or days and in Ventura, there is no way to keep the computer from sleeping and it causes major issues for cloud work.

EDIT: Check under the 'advanced' tab in Displays settings and check 'Prevent automatic sleeping when the display is off" and see if that works for your situation.

FIXED (for me): I have been struggling with my external hard drive “disk not ejected properly” message for years. It randomly and often disconnects my external hard drive, usually during sleep. I have tried everything, including new drives & new enclosures. The other day, I decided to disconnect an old USB 3 hub I have had plugged into a USB port for years. It worked! No more disconnecting of my external drive! I hope this works for some of you!

I may have found a solution.. time will tell.

I'm running a 14" MBP M1 Pro on Ventura 13.1, connected to a Bridge ProDock, connected to a Studio Display and an internal hard drive. I too am having the "disk not ejected properly" messages after waking from sleep. I thought it may initially be due to my Bridge ProDock, but I don't think that's the case—especially after finding this thread.

I went into System Preferences > Displays > Advanced and found this toggle option. I suspect this may address the issue, but I only just found it: Prevent automatic sleeping on power adapter when the display is off.

Preventing sleep in this way has solved the problem for me.

I use my MBP in clamshell mode in a Brydge vertical dock with my HDD connected to that, and an external display & peripherals.

• I have Settings > Battery > Low Power Mode set to "Never"
• I have Settings > Displays > Advanced > Prevent automatic sleeping on power adapter when the display is off set to "on"
• In have Settings > Desktop & Dock > Hot Corners > bottom-right set to Put display to sleep

When I want to turn off the display, I basically mouse into that bottom right corner. My settings prevent sleep, which seems to prevent my drives from being automatically disconnected. It still 'locks' the display to wake up the screen, and it still allows Time Machine to run its backups, which I like. I'm unsure whether there's any downside to not allowing Sleep.

I've now been totally free of spurious disk ejects for 35 days, that's at least 400+ sleep/wake-up cycles. Any lingering doubt I had re Apple's latent race condition defect associated with its USB 3.0 implementation is history. They broke it and now won't fix it and are too mercenary to admit it. Blame it on the hub manufacturers and keep pushing the worthless SMC/NVRAM reset koolaid. I encourage any macOS user with an external monitor with a built-in USB hub to try attaching any external drive enclosures to it rather than ANY of the ubiquitous multi-port hubs on the market. They probably all use the same chip-set.

FWIW I have been stuggling with this for a few months now since buying a Seagate 12TB desktop drive.

I've actually upgraded to Sonoma but have the same issue.

I can shed a little light on this though - it appears that the issue is related to the firmware on the external drive.

I have 2xLacie 8TB Porsche design drives and the 16TB Seagate. The issue is only ever with the Seagate, the Lacie are always mounted without any issues. I'm using an M1 MacBook Pro and have the drives running from the built in hub on my Studio Display. Moving the Seagate to a free port directly on the Mac makes no difference. The Mac is pretty well always run in clamshell mode.

The Seagate is not consistent. It will sometimes disconnect overnight while other times it's fine. I even tried mounting it to a separate machine - a MacBook Air M1 - and had the same issue. It's annoying because the Seagate is my Time Machine drive. Luckily I also have TM set to backup to my NAS, so I have alternating backups.

I suspect that it's something to do with the way some controllers handle sleep mode. Seagate drives are the only ones that have had this issue for me (I have a portable Seagate that did the same).

This long standing bug is only fixed by not using sleep and only turning off the display function or using screen saver until Apple really fixes the issue.

In Ventura, this option is now found in Displays / Advanced / Battery & Energy / . There is a toggle button for "prevent automatic sleeping on power adapter when the display is off"

Hi just throwing my hat in as well. Having the issue since months on my MBP M1.

Did anyone find an entry in a log file that documents the moment when a drive is being ejected?

I might, but not sure, so if some of you could cross check?

For the time when the drives have been ejected, there is an entry in the wifi.log file (-> see below)

The issue applies to external drives, no matter what connection type (USB or TB), with or without external power supply for the drive, connection over a dock (OWC) or directly, or daisy chained. Sometimes drives will not be mounted back. In more than one instance even my internal Data volume has been ejected.

In one case, an external disk has been ejected several time while doing a search in spotlight for a file.

Apple so far has been going though the standard routine, including deep diagnostics (nothing found) but replacing the IO Ports (USB-C), nothing changed, even under Ventura...

So far the problem only happens to be on my MBP M1, not on my other, older Macs.

I do get the issue on an erratic basis. Some days are just fine, and some... oh well... So far I could not figure out if there is something different between the turbulent days and the days when is just runs smoothly. After trying most or all of the common suggestions - looking at the wifi.log file, I might turn off WLAN on my MBP for a while and see if it happens again or not.

I'm not familiar with your hardware or your version of macOS, but I've had this problem for donkeys' years on my Pro, now running High Sierra 10.13.6. (Why such an old Pro and an old OS? Mine is the last Pro you could modify, before Apple began soldering everything in place.). I've tried all those stupid solutions you mentioned including removing the battery from the machine between troubleshooting iterations. However, just recently something occurred to me that I'm now investigating. What I have been in the habit of doing to wake the machine up is tapping on the track pad until I get a response. Sometimes this tapping, or rubbing, gets very vigorous when the machine fails to immediately awake, and when it does I often but not always get the awful, dreaded messages that my external drives, including my RAID drives have been incorrectly ejected. I've only had one catastrophic failure of an SSD in an external enclosure I use as a secondary backup device, but it and the enclosure were under warranty (the great folks at OWC,) so the drive was replaced, no questions asked. Now I am experimenting with different ways to wake the machine up, and I am avoiding the track pad completely. My theory: some gesture on the track pad is signaling the OS to eject the drives. I've never understood the track pad's gesture interface well enough to use it effectively, but that does not mean I am not inadvertantly using it in a counter intuitive way, and causing the drives to eject. So far the spacebar seems to always work and I have not had any of my disks eject since embracing this idea. Go figure... Your mileage may vary, but at least this sort of experimentation is low-key and unobtrusive.