Unexpected Disk ejects of external SSD

[BrianBaughn]

Overheating definitely causes disconnects…so the particulars of how hot an SSD gets plus how much of that heat can be dissipated by the enclosure is a factor.

My external SSDs aren't being used for long-lasting active processes or transferring large amounts of data at once.

 

[Boyd01]

That is interesting. I have quite a few Samsung T7's and a couple WD Black game drives, all are pre-packaged in their own enclosures. As mentioned, I process very large geodatasets, getting ready to export about 7 million map tiles (small .jpg files) tonight that could take 12 hours or more. The external drive can get quite warm with this kind of hammering!

But I've never seen any correlation between that and the mystery disk ejects. Like I said, those mainly happen to disks that are mounted but not in use. Anyway, doesn't happen very often.

 

[kagharaht]

Overheating definitely causes disconnects…so the particulars of how hot an SSD gets plus how much of that heat can be dissipated by the enclosure is a factor.

My external SSDs aren't being used for long-lasting active processes or transferring large amounts of data at once.

Yes that possible. It also happens when it's just sitting there. Like "HobeSoundDarryl" has mentioned before, and he has done extensive testing, it's the Mac OS thats doing this. No rhyme or reason. It's quite annoying as at times it will not happen for weeks or months despite intense usage. Then all of a sudden it starts to do it then stops.

 

[kagharaht]

It just happened again. The last incident was December 14. So it stayed connected 15 days this time. I report this to the feedback at Apple and I'll keep doing so when it happens every time. Who know, maybe one day someone will actually read it.

Update: I forgot I did turn on sleep a couple of days ago. I've been running Topaz Processes for weeks now non stop and decided to let the iMac sleep when it completes the job. I turned that on a couple of days ago. So I think Sleep has a big effect on external SSD drives randomly disconnecting at least for me. Back to never sleep now since that helps keep it connected for a long time.

 

[kagharaht]

Jan 24 both SSD ejected overnight. Both are connected directly on the iMac M3. This time using OWC Thunderbolt 4 cable. The SSD Crucial P2 2TB 3D NAND NVMe PCIe M.2 SSD and Crucial BX500 2TB 3D NAND SATA 2.5-Inch Internal SSD. I also have 2 Seagate HDD connected directly also. Those never sudden eject. Just the SSD guys. Almost a full month this time. Mac OS 15.2

 

[BrianBaughn]

Sleep is OFF on my M1 Mac Studio so that might explain why I haven't experienced disconnects. Additionally, my two Acasis TBU405 Air enclosures (containing Silicon Power SSDs) are connected via a powered Kensington SD2600T Thunderbolt 4 hub.

 

[Boyd01]

Have not had any unexpected disk ejects since I made the previous post here over a month ago. I always have 3 Samsung T7's and one WD Black external USB SSD's directly connected to my 2018 Mini which has been running 24/7. I turn sleep off on all my Macs.

 

[kagharaht]

I turned off Sleep and turned off Low Power Mode also. Thing was just sitting there overnight. Good thing I only use them for storage and scratch disk when doing my Tooaz Projects.

 

[kagharaht]

Ok it just did it again. Both SSD. . I think I’ll just use the HDD. For scratch disks.

 

[HobeSoundDarryl]

Again, through much experience with this issue, many get on this track that it's sleep functionality but I don't think so. I suspect it seems to be sleep because the time we let our Macs sleep is a LOT of time. Whatever actually causes this problem then has lots of time to occur. When we re-wake the Mac after many hours and see the unexpected ejection, we jump to a conclusion that sleep is the cause.

I suspect that's not true but just coincidental. For example, OP describes it happening while actively rendering a HB file to the drive. Obviously, neither Mac nor the drive can be asleep during active writes. All other variables like cable, specific enclosure, user settings, etc are the same. I've experienced the same when using externals as scratch drives for FCPX: both Mac and the drives are definitely awake. If the cause is sleep, those examples don't allow sleep, so it seems sleep is NOT the cause.

However, if someone still believes it's sleep, unhook the same drive cable from the Mac having the problem and hook it to a Mac running macOS before Big Sur. Put that Mac to sleep a thousand times. Set it up to sleep and wake at exactly the same time as the new Mac and leave it alone for a few days. You will very likely find there is no "unexpected ejection." I can do that trick myself: unhook the problematic drive from "latest & greatest" Mac, hook that same cable to an older Mac running MacOS < BigSur and that drive is perfectly stable again... as it was for a few years while I still used that Mac and- BTW- let it sleep every night.

My best guess is that macOS (BigSur and newer) ports "crash" and reboot and some enclosures handle this better than others... including some enclosures from the same manufacturers. I'm convinced Apple needs to go in there and debug the code.

Else, (I think) those of us experiencing this (which is MANY) are chasing red herrings when we head down these popular paths of tweaking settings, installing an app to keep the drive awake at all times, etc. No tweak seems to "stick" for all. What is common to all is macOS (since BigSur).

 

[kagharaht]

Again, through much experience with tis issue, many get on this track that it's sleep functionality but I don't think so. I suspect it seems to be sleep because the time we let our Macs sleep is a LOT of time. Whatever actually causes this problem then has lots of time to occur. When we re-wake the Mac after many hours and see the unexpected ejection, we jump to a conclusion that sleep is the cause.

I suspect that's not true but just coincidental. For example, OP describes it happening while actively rendering a HB file to the drive. Obviously, neither Mac nor the drive can be asleep during active writes. All other variables like cable, specific enclosure, user settings, etc are the same. I've experienced the same when using externals as scratch drives for FCPX: both Mac and the drives are definitely awake. If the cause is sleep, those examples don't allow sleep, so it seems sleep is NOT the cause.

However, if someone still believes it's sleep, unhook the same drive cable from the Mac having the problem and hook it to a Mac running macOS before Big Sur. Put that Mac to sleep a thousand times. Set it up to sleep and wake at exactly the same time as the new Mac and leave it alone for a few days. You will very likely find there is no "unexpected ejection." I can do that trick myself: unhook the problematic drive from "latest & greatest" Mac, hook that same cable to an older Mac running MacOS < BigSur and that drive is perfectly stable again... as it was for a few years while I still used that Mac and- BTW- let it sleep every night.

My best guess is that macOS (BigSur and newer) ports "crash" and reboot and some enclosures handle this better than others... including some enclosures from the same manufacturers. I'm convinced Apple needs to go in there and debug the code.

Else, (I think) those of us experiencing this (which is MANY) are chasing red herrings when we head down these popular paths of tweaking settings, installing an app to keep the drive awake at all times, etc. No tweak seems to "stick" for all. What is common to all is macOS (since BigSur).

I’m giving up on external SSD for constant read/write work from now on. Until Apple fixes this bug. I’ll use my external HDD for now. I’ll just keep these SSD to store files for backup use.

 

[Adora]

Again, through much experience with this issue, many get on this track that it's sleep functionality but I don't think so. I suspect it seems to be sleep because the time we let our Macs sleep is a LOT of time. Whatever actually causes this problem then has lots of time to occur. When we re-wake the Mac after many hours and see the unexpected ejection, we jump to a conclusion that sleep is the cause.

I suspect that's not true but just coincidental. For example, OP describes it happening while actively rendering a HB file to the drive. Obviously, neither Mac nor the drive can be asleep during active writes. All other variables like cable, specific enclosure, user settings, etc are the same. I've experienced the same when using externals as scratch drives for FCPX: both Mac and the drives are definitely awake. If the cause is sleep, those examples don't allow sleep, so it seems sleep is NOT the cause.

However, if someone still believes it's sleep, unhook the same drive cable from the Mac having the problem and hook it to a Mac running macOS before Big Sur. Put that Mac to sleep a thousand times. Set it up to sleep and wake at exactly the same time as the new Mac and leave it alone for a few days. You will very likely find there is no "unexpected ejection." I can do that trick myself: unhook the problematic drive from "latest & greatest" Mac, hook that same cable to an older Mac running MacOS < BigSur and that drive is perfectly stable again... as it was for a few years while I still used that Mac and- BTW- let it sleep every night.

My best guess is that macOS (BigSur and newer) ports "crash" and reboot and some enclosures handle this better than others... including some enclosures from the same manufacturers. I'm convinced Apple needs to go in there and debug the code.

Else, (I think) those of us experiencing this (which is MANY) are chasing red herrings when we head down these popular paths of tweaking settings, installing an app to keep the drive awake at all times, etc. No tweak seems to "stick" for all. What is common to all is macOS (since BigSur).

You are right it's happening even more when not sleeping. From 15.0 Beta 1 to 15.3 nothing changed with this problem.

I have all kinds of external drives and it doesn't even matter if it is powered by the port or external, connected to a wired Thunderbolt dock a USB Hub or the Mac itself.

The only thing they have in common is USB 3.x.

With Thunderbolt drives this does not happen ever.

 

[HobeSoundDarryl]

Anyone else needing clarification when experiencing this: unhook same cable to problematic drive and connect to Mac running macOS <BigSur. All variables beyond the port of the new Mac will be preserved to rule out/in cable, enclosure, firmware, age of enclosure, power supply, drive, etc. All that is changing is Mac. Magically, I bet the “unexpected ejections” cease in almost every case.

OR, if you have a PC, hook the same cable to it and leave it there for days. Again, magically, I bet cable to drive/firmware/enclosure/power supply/etc. are perfectly stable. If the problem is caused by any red herring redirects (AKA “NOT Apple”) it should repeat no matter what Mac or PC is used. A bad cable is a bad cable. Buggy firmware is buggy firmware. “Too old” is still “too old” when hooked to other computers. Etc.

If you happen to have a Mac that can run both pre and post Big Sur, you can do the ultimate test... as many have. Hook the same cable to it with it running pre-BigSur and leave it up to days to verify stability. Sleep it, wake it, set it to auto sleep & wake, etc- whatever you want to think might be the catalyst for unexpected ejection. You’ll likely find you have a stable enclosure that remains connected.

Now change just ONE variable: update macOS. Leave everything else exactly the same. Watch your unexpected ejections begin.

But let’s not jump to a conclusion yet. Perhaps this is a rare timing coincidence? So downgrade the Mac back to a macOS version before BigSur again. Watch the drive become perfectly stable again.

If you really want to blame anything other than the ONE variable you changed, repeat the whole experiment again.

Test broader? Mix in other drives including those that still work but you've mostly retired just to rule out/in what is sometimes slung as “older firmware.” I’ve done this with 20-year-old enclosures, some of which are perfectly stable with > BigSur macOS. What does the U in USB stand for again? Those seem fine with any PC and Macs running pre-BigSur macOS. But change the one key variable and bam: unexpected ejections.

As long as you keep the testing to a single variable change, you eventually arrive at where this problem most likely lies. Since a simple web search shows that MANY have this problem, it can’t be just you, just your settings, just this one drive, just this one cable, just this one firmware version, etc. There are only 2 variables that are identical for everyone affected: Mac and macOS.

Since other USB stuff connected to new Mac seems fine, it’s probably not Mac hardware. It still could be but that probably deserves more benefit of doubt since this seems isolated to only this one kind of USB attachment. So what’s left? And therein is probably the culprit.

Now before 50 guys jump in claiming "my USB connected drive works just fine with latest macOS", YES, not every drive unexpectedly ejects- just lots of them. Others are perfectly stable. This is not a brand thing or a cost thing or- apparently- and age (of drive) thing, etc. I worked through many tries to find one for my own needs that has remained connected without ejection for a couple of YEARS now. So this bug(s)- whatever it/they is/are- seems to affect only some drives, not all of them. If you have such a drive, the above can help you shortcut past all of the red herring redirects to narrow right in on where the problem most likely originates.

I miss “just works” Apple.

 

[PaulD-UK]

"unhook same cable to problematic drive and connect to Mac running macOS <BigSur."
"Now change just ONE variable: update macOS."

The problem is that that is not just 'ONE' variable...
'Mac running macOS <BigSur.' is by definition is an Intel Mac, with a (third party) USB Host chipset applicable for use with an Intel CPU.
'...update macOS' is increasingly likely to be with a Mac using Apple Silicon with an Apple designed USB Host controller which is an integral part of their Thunderbolt 4 Host controller, with it's timing/retiming* chips...

So the TWO variables (with multiple sub-sets for M1-M4) are the Mac designed* OS, and the Mac designed hardware it is running on.

** With a third variable being Apples interpretation of the USB-IF 'standards...'
* No USB4 SSD cable with a length greater than 0.8m works. Unless it is a TB4 cable with Intel 'active' retiming chips in it.

My GUESS is that Apple's 'interpretation' of how USB 3.* should be done, is zealously implemented in Mac hardware... Probably more rigorously than the third-party Windows-looking device chip-designers out there.

Solution?

 

[HobeSoundDarryl]

….except those with late generation Intel Macs can run BOTH macOS before BigSur and update to BigSur or newer and they report the problem. If Intel Mac hardware is less rigorously applying zealously implemented USB standards, unexpected ejections shouldn’t suddenly appear when they make the hop. And when some of them downgrade again because they need the drive more than they need the macOS upgrade again, all is generally well again.

What’s the one thing that changes for them? MacOS versions.

We CAN jump to an assumption that the more rigorous USB implementation is limited to only Silicon Macs (though obviously not true by example just offered) anyway but we can just as easily assume the “half empty” view of that too.

IMO: “more rigorously” should yield less problems connecting to USB stuff, not more. Then apply the same idea to now 5 generations of macOS rigorous testing to fix a broad problem that remains unfixed.

Else, the implication is that Apple has implemented a USB standard right and all these other players are too lax to work right with a properly implemented, “UNIVERSAL” standard. That’s asking for a very big leap of faith in one brand being right.

 

[PaulD-UK]

I was speculating why my Yottamaster USB 3.1 USB-C inclosure with ASM controller chip doesn’t work with a TB3 cable. Immediately drops the connection, but works fine with its cheap in-the-box cable.
Too much timing accuracy destroys it…

 

[bzgnyc2]

I am curious for those who know the exact model of SSD in your enclosures and are experiencing this issue, are your SSD the DRAMless / HBM design? Those would include WD Black SN750E and SN770 and Samsung 980 and 990 EVO (note it also seems Apple's drivers haven't liked Samsung's TRIM implementation since at least Monterey).

You can lookup whether your SSD uses DRAM here:

TechPowerUp

Solid-state-drive database with specifications for products launched in recent years. Includes specs, photos, and technical details.

www.techpowerup.com

 

[RickBrick]

I was speculating why my Yottamaster USB 3.1 USB-C inclosure with ASM controller chip doesn’t work with a TB3 cable. Immediately drops the connection, but works fine with its cheap in-the-box cable.
Too much timing accuracy destroys it…

My Satechi Thunderbolt 4 enclosure with Samsung 970 EVO onboard worked perfectly fine until Sequoia 15.3. It suddenly began to eject itself almost instantly after plugin (after few minutes under load at best) since the update (I almost positive of the timing). I thought I somehow damaged default cable, because with regular Baseus Usb-c (3.1, I believe) cable enclosure works fine. So I bought a new satechi tb4 cabel, and after self-ejecting issue re-emerged, I googled this topic... F me 🙃