Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
It is possible that an enclosure manufacturer -- especially the ones that sell as a bundled solution rather than a component -- ties any bundled drive to the enclosure or otherwise employs custom firmware limiting its usability outside that brand of enclosure/intended use case.

I generally haven't seen that with standalone drives and enclosures. My experience in those cases has been that the drive can be moved internal to external and enclosure to enclosure. I am not saying none exist though I would consider such enclosures fundamentally flawed. This is a good reminder of one of the reasons why I don't generally buy packaged drives/enclosures (previously HDD and now the same with NVMe SSD).
Who knows... but I really don't think so as you can move the hard drive from the Sabrent to a different enclosure and re-format it there and it'll work - so it's not locked to a single enclosure per say. The Sabrent I've been using is this one (there's a newer version out - which has reviews saying it does the same bad things as well), which is a standalone unit (i.e. not an enclosure left over after I shucked/removed the HDD from it) and specifically a tool-less swap unit, meant to quickly swap drives in and out of it (like it's not meant for long term storage), and it still misbehaves.

The Lacie I just tested (which Seagate owns, the drive type the poster above you uses) WAS a standalone unit (i.e. the HDD and enclosure were sold together as one unit) and that WILL read a drive pulled out of the Plugable unit or vice versus (and that enclosure has a similar use-case to the Sabrent as it's also tool-less and top-loading, and meant for quick drive swaps) and that one does not do the bad sector-type things the Sabrent does. The Sabrent is just bad - and/or whatever chipset and/or USB bridge they use (or how their firmware programmed it or whatever) is bad - as are some of the older ones I've tried (which I can't tell you brand/models as I don't have them anymore to double-check).
 
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
So I again have to default to what ChatGPT tells me to reply to you in the detail you need - and as I now feel like I'm the intermediary between this post and my ChatGPT overlord, I won't hold it against you if you don't feel like replying lol (all the answers seem to be in the below copy and paste though! - and is what I saw in real-time as I was doing all this testing over Terminal which ChatGPT led me through).

I'll just say this as far as ChatGPT -- it's amazing but as my boss told me when I first became a manager, "you're accountable". You can delegate action but you can't delgate accountability.

Then I've used ChatGPT for things I know to get a sense of what it can do and it does make mistakes. So we should allow that somethings my have gotten lost through this game of telephone...

I also DID purchase that dual-drive OWC HDD enclosure earlier today - so essentially giving up on this (although I would love love LOVE to get to the bottom of this still, as it's plagued me for more than a decade!!!) - and will just use an enclosure and no more bare HDD's in my own house (although I'll still store bare HDD's at my parents house who have limited space in their small fireproof safe -in little padded anti-static boxes- which will be pulled from that same OWC enclosure so I know they can be read later on).

I'm more than happy running any more tests you want, or pasting in the results if I ran them before. Here's the copy and paste from ChatGPT:


Thanks for the insights. Here’s what I can clarify based on our tests:

  1. Sabrent vs. Plugable Sector Size Handling:
    • The Sabrent forces a 4K sector size (4096 bytes).
    • The Plugable presents the drive as 512-byte sectors (512e).
    • The drive itself is factory 512e but is being interpreted differently depending on the enclosure.

One thing I've learned since this started is that some newer drive seem to be configurable or even dynamic about 512e versus 4Kn mode. I find this weird for the reason that such would be prone to the issues you are experiencing. I think a drive needs to pick a lane and stay there...but that ship has sailed...

Also FYI I just checked my old HDD (which all date to 20-teens as in 201x) and they are all 512e. Then I do have them connected to my Mac via a Sabrent enclosure that uses the same JMicron controller mentioned above and they do present my drives as 512-byte sectors exactly as expected (i.e. no additional translation / mode switch).

Then I found this article which may shed light on what's going on:

FYI, all my drives are 1TB or less. But notice in the above that their enclosures behave differently for larger drives. Then there may be a firmware update applicable to your situation...

  1. dd Read/Write Differences:
    • When formatted in the Plugable, dd works fine in the Plugable, but fails in the Sabrent.
    • When formatted in the Sabrent, dd works in the Sabrent, but while Plugable could dump data [and it matches 100%], macOS couldn't recognize the drive.
    • This suggests the enclosures are presenting different raw sector alignments, causing macOS to misinterpret the partition structure.

What's a little unclear to me from the above is whether the drive completely unreadable/inaccessible or just not mountable. If the drive is unreadable/inaccessible when placed in the Sabrent enclosure then I would say the problem is on the Sabrent side and it's not realistic to expect macOS to workaround that.

Even then if a drive is partitioned assuming 512-byte sectors then the partition map (and thus where everything is stored relatively on the disk) won't be visible if read back assuming 4096-byte sectors even if it is accessible. This is inherent in the GPT specification which works in units of sectors. I guess they assumed that wasn't dynamic when they designed the standard.

If Windows let's you move the same drives back and forth across enclosures despite the changing sector size issue, it is possible they enable some special drivers/controler options that stop the Sabrent from switching to 4Kn or maybe force the Plugable 4Kn. Or maybe Windows has a generic workaround to deal with partition maps written assuming one sector size and read back with another. I'd have to spend a lot of time with Windows to figure out what they are doing over there and I literally haven't even booted Windows on my home computer in years.

  1. Partition Structure & Raw Data:
    • I agree that if macOS sees different partition structures depending on the enclosure, then something at the raw data level is different.

Agree and if that is so I would say full stop do not use that enclosure. Though there are a lot of protocols involved, fundamentally, a USB-SATA (etc) enclosure should present the same contents of the drive in the same order as if the drive was connected directly (e.g. reading sector 0 when connected via USB should produce the same results as reading sector 0 when connected directly, same for sector 1, ...). In my mind an enclosure that doesn't do that is fundementally flawed.

    • This aligns with the theory that one of the enclosures (likely the Sabrent) is forcing sector translation at a hardware level.
  1. LaCie Enclosure Test – More Evidence Against Sabrent:
    • Today, I tested a LaCie G-Drive enclosure, which is known to be Mac-friendly.
    • A drive formatted in the Plugable was instantly recognized in the LaCie with no issues [and vice-versa].
    • This further suggests that enclosures like Plugable and LaCie do not modify sector sizes, while the Sabrent (and other enclosures I’ve used with this same behavior in the past) are forcing sector changes.
  2. Enclosure Behavior:
    • The Plugable and LaCie enclosures do not modify the drive’s sector formatting, meaning they present the disk as-is.
    • The Sabrent forces a 4K sector size, which appears to break compatibility when moving between enclosures.

Agree with all the above.

    • The fact that moving between enclosures results in an unreadable drive suggests that macOS does not handle sector size mismatches well.

I agree though would add that GPT (the industry standard for partitions maps on the PC) is not designed for sector size mismatches and I don't consider that a bug in macOS for not working around that.

  1. Next Steps?
    • The missing piece is whether macOS itself can handle a drive that changes sector sizes depending on the enclosure.

    • If this is purely an enclosure-level translation issue, then any enclosure that doesn’t modify sector size should work consistently.

That has been my experience (which hasn't yet included enclosures that translate or untranslate sector sizes).
 
Then I found this article which may shed light on what's going on:
I've done a crapton of research since my last post, including with the tech support people of both enclosures I'm using - both the Plugable, and OWC dual, and that article hits the nail on the head. It says "I ultimately found the culprit, namely the JMicron controller of the Sabrent enclosure".

Yup, that's it. JMicron is the devil. Never, ever, buy anything with that chipset - ESPECIALLY if on a newer Mac (where it's seemingly even worse than on Windows - but don't worry, there's still plenty of issues on Windows too lol).

So to update, the Sabrent which uses a JMicron controller is in the trash. I broke it with a hammer first so I felt better lol.

My Plugable (which is open top, not suitable for long-term use) uses an ASMedia chipset, and although I'm not getting the advertised 10gbps (because of course only Intel Macs and all Windows computers get that speed, it's only 5gbps on any Mac with a Silicon M1/M2/M3/M4 processor - i.e. ANY Mac made in the last ~4-5 years), it's still a keeper because it reads ANY drive (including ones pulled from inside my 2009 Mac Pro), and does NOT randomly disconnect! Plus 7200rpm mechanical drives don't really benefit much from 10gbps anyway...

OWC, which was specifically mentioned here (and pictured below - the OWC Mercury Elite Pro Dual with USB 3.2 Gen 1 and eSATA), and a brand which is well-known in Mac/Apple circles, is a POS too since it uses the JMicron JMS562 chipset - and a SUPER old one from 2013! That drive WAS able to backup all 18TB of my data perfectly fine (took several days of course), BUT it will randomly disconnect - a seemingly well-known (other) issue with JMicron chipsets - and seems to be way more flaky on Apple Silicon than the older Intel-based Macs. And of course OWC says they've never heard of this problem before, despite over a dozen complaints on their Amazon listing about this same disconnecting issue (which for Mac people will be the fly-out which says "Disk Not Ejected Properly" - which can lead to data loss...).

Screenshot-2025-02-18-at-8.24.19 PM.jpg


So (and I might make a separate topic on this), I'm back to the drawing board looking for a RELIABLE external enclosure (hopefully dual 3.5"), which does NOT use a JMicron chipset... ASMedia or Realtec seem to be the way to go and be WAY better... but manufacturers commonly don't like to say which they use so it's a pain.... open to any suggestions.
 
  • Like
Reactions: buggz
I've done a crapton of research since my last post, including with the tech support people of both enclosures I'm using - both the Plugable, and OWC dual, and that article hits the nail on the head. It says "I ultimately found the culprit, namely the JMicron controller of the Sabrent enclosure".

Yup, that's it. JMicron is the devil. Never, ever, buy anything with that chipset - ESPECIALLY if on a newer Mac (where it's seemingly even worse than on Windows - but don't worry, there's still plenty of issues on Windows too lol).

Yes seems JMicron had a special logic. SNAFU. They probably thought they were doing the right thing -- an optimization but in practice it breaks things in a bad way.

There does seem to be a firmware fix available and newer devices (with newer chipsets and/or firmware) may not have this issue. But to your point below, how would you know before you buy?

For others out there who already have an enclosure with a JMicron chipset, I wouldn't junk if it had been working fine. But know that a) you should write down the sector size it is reporting back to macOS for each drive in case you have to move it and b) swapping drives (especially >2TB) may not work as expected in the future.

So to update, the Sabrent which uses a JMicron controller is in the trash. I broke it with a hammer first so I felt better lol.

I am sure that felt good!

My Plugable (which is open top, not suitable for long-term use) uses an ASMedia chipset, and although I'm not getting the advertised 10gbps (because of course only Intel Macs and all Windows computers get that speed, it's only 5gbps on any Mac with a Silicon M1/M2/M3/M4 processor - i.e. ANY Mac made in the last ~4-5 years), it's still a keeper because it reads ANY drive (including ones pulled from inside my 2009 Mac Pro), and does NOT randomly disconnect! Plus 7200rpm mechanical drives don't really benefit much from 10gbps anyway...

Yes almost no single mechanical drive today can sustain more than 5Gbps. As far as I know the only exceptions are the Seagate Exos 2X18, which are really intended for specialized enterprise situations anyway.

The above is the first I've heard of a USB 3.2 Gen2 device that only negotiates at 5Gbps with Apple Silicon Macs but properly negotiates 10Gbps "everywhere" else. Perhaps a flaw in Apple's Thunderbolt/USB implementation or macOS drivers for such. Or perhaps ASMedia only tested their chip for this against Intel and other popular PC USB chips and as such autonegotiates wrong...but figuring all that out would probably require some protocol and perhaps hardware-level debugging...

I have heard of a similar issue with one model of OWC Thunderbolt/USB NVMe SSD drive where it autonegotiated to USB 10Gbps on Intel macs w/TB3 instead of TB3 (40Gbps nominally) and they may also have been using an ASMedia chip. An entirely different chipset than your situation since it was for NVMe but it just may highlight the issue that they may not have perfected their link autonegotiation fallback logic yet (the testing permutations of which are immense).

In any case, I've been pleased with my abeit limited experience with a completely different Plugable product. Their tech support was very knowledgable and very helpful. Using a Mac, referencing the SMART protocol, and mentioning kernel extensions didn't scare them away at all. They knew their product and the related Mac-side issues and I didn't have to escalate to get to the right person.

So (and I might make a separate topic on this), I'm back to the drawing board looking for a RELIABLE external enclosure (hopefully dual 3.5"), which does NOT use a JMicron chipset... ASMedia or Realtec seem to be the way to go and be WAY better... but manufacturers commonly don't like to say which they use so it's a pain.... open to any suggestions.

Honestly not keeping up with the HDD market as I am not planning to buy any more of them or related enclosures. I've been living off a combination of newer SSDs and 7-10 year old HDDs.

From a theoretical perspective, I do note the market for USB<->SATA basically comes down to 3 chipsets:

I also notice the JMicron-based unit in their tests generally scored the lowest. Another knock against them even though its more likely that an HDD will be the performance bottleneck in your situation.

In any case ruling out the JMicron that leaves ASMedia and now VIA. Plus the RealTek you mentioned. From there I'd look the manufacturer's non-Windows support (e.g. Mac and Linux) and firmware updates. Also availability in things like smartmontools (https://www.smartmontools.org/wiki/TocSupport). Even if you don't plan to use that tool (or macOS blocks some aspects of it), that just signals to me a) more open and supportive of 3rd party support and b) lots of use by fairly technical people.

As an example a Plugable device with either a ASMedia or RealTek chipset seems a relatively good bet along these criteria. Assuming Plugable has a product that otherwise meets your needs (they don't appear to make a product for every permutation of market need).

Otherwise you can try to use the database at Smartmontools to see what chipsets a particular manufacturer used (at one point in time but of course manufacturers can and do silently change these between production runs) and also see if the manufacturer explicitly mentions the chipset and/or let's it slip out on any support page for firmware updates.

Unfortunately I think outside the enterprise, etc market it comes down to some trial and error. On the upside your experiences have given you some things to look out for during that initial test drive and perhaps allowed you to build up a set of tools to check things out before you commit to a product.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.