{
"path": "/my-dead-crucial-ssds-werent-dead-they-just-needed-a-better-cable-and-a-firmware-update-uy70g9n",
"site": "at://did:plc:li7aafca7mhntzdnrehbezgc/site.standard.publication/3mfrvxf3q5x42",
"tags": [],
"$type": "site.standard.document",
"title": "My \"Dead\" Crucial SSDs Weren't Dead — They Just Needed a Better Cable and a Firmware Update",
"content": {
"$type": "blog.pckt.content",
"items": [
{
"$type": "blog.pckt.block.text",
"plaintext": "A couple years ago, after a macOS update I honestly can't remember anymore, two of my external SSDs became unreadable almost at the same time. Not one — two. Both encrypted APFS volumes. Both completely unreachable."
},
{
"$type": "blog.pckt.block.text",
"plaintext": "I assumed the worst, threw them in a drawer, and moved on."
},
{
"$type": "blog.pckt.block.text",
"plaintext": "Fast forward to now, where SSD prices are painful enough that \"just replace them\" felt a lot less appealing than it used to. Since both drives had failed in basically the same way, I figured it was worth taking one more look before writing them off."
},
{
"$type": "blog.pckt.block.text",
"plaintext": "That turned out to be the right call."
},
{
"$type": "blog.pckt.block.horizontalRule"
},
{
"$type": "blog.pckt.block.heading",
"level": 2,
"plaintext": "The Setup"
},
{
"$type": "blog.pckt.block.text",
"plaintext": "One was a 4TB Crucial X9 Pro. The other was a 2TB Crucial X10 Pro. Both had been formatted as encrypted APFS volumes on macOS and had been rock solid — until they weren't. After that mystery macOS update, both started behaving almost identically:"
},
{
"$type": "blog.pckt.block.bulletList",
"content": [
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "APFS containers unavailable"
}
]
},
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "Intermittent I/O errors"
}
]
},
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"facets": [
{
"index": {
"byteEnd": 54,
"byteStart": 41
},
"features": [
{
"$type": "blog.pckt.richtext.facet#code"
}
]
}
],
"plaintext": "Drives disappearing and reappearing from diskutil list"
}
]
},
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "Failed filesystem checks"
}
]
},
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "Eventually, drives that wouldn't mount at all"
}
]
}
]
},
{
"$type": "blog.pckt.block.text",
"plaintext": "At the time, two drives going down simultaneously felt like a hardware fluke or just bad luck. In hindsight, that should have been the first clue something else was going on."
},
{
"$type": "blog.pckt.block.horizontalRule"
},
{
"$type": "blog.pckt.block.heading",
"level": 2,
"plaintext": "The First Clue: The Cable"
},
{
"$type": "blog.pckt.block.text",
"plaintext": "When I pulled the drives back out and started digging in, the first thing I noticed was that swapping from a generic USB-C cable to a proper Thunderbolt 4 cable made a dramatic difference almost immediately. The devices stopped randomly disconnecting, the GPT partition tables became readable, and recovery tools could actually scan the APFS containers without the drives vanishing mid-scan."
},
{
"$type": "blog.pckt.block.text",
"plaintext": "That alone was telling. High-speed NVMe USB enclosures are surprisingly sensitive to cable quality — USB signaling integrity matters a lot more than most people expect, especially on Apple Silicon Macs with APFS-encrypted volumes doing heavy metadata reads during mount attempts. A marginal cable can cause the bridge chipset to choke right at the worst possible moment, and macOS interprets that as \"no filesystem here\" rather than \"the connection just hiccuped.\""
},
{
"$type": "blog.pckt.block.text",
"facets": [
{
"index": {
"byteEnd": 36,
"byteStart": 9
},
"features": [
{
"$type": "blog.pckt.richtext.facet#code"
}
]
}
],
"plaintext": "A run of sudo gpt -r show /dev/disk6 with the better cable confirmed the APFS partition was actually still there — the GPT was intact, the APFS partition entry was intact, and the data was almost certainly still sitting on the NAND. The drive wasn't dead. It had just been getting knocked offline every time macOS tried to read the encrypted APFS metadata over a flaky connection."
},
{
"$type": "blog.pckt.block.horizontalRule"
},
{
"$type": "blog.pckt.block.heading",
"level": 2,
"plaintext": "Recovery"
},
{
"$type": "blog.pckt.block.text",
"plaintext": "With a stable connection, I ran R-Studio against both drives. It recognized the encrypted APFS containers, accepted the passwords, and successfully recovered the directory structures and data from both."
},
{
"$type": "blog.pckt.block.text",
"facets": [
{
"index": {
"byteEnd": 142,
"byteStart": 66
},
"features": [
{
"$type": "blog.pckt.richtext.facet#bold"
}
]
},
{
"index": {
"byteEnd": 401,
"byteStart": 393
},
"features": [
{
"$type": "blog.pckt.richtext.facet#code"
}
]
},
{
"index": {
"byteEnd": 422,
"byteStart": 418
},
"features": [
{
"$type": "blog.pckt.richtext.facet#italic"
}
]
}
],
"plaintext": "If you're in a similar situation, the important thing to know is: don't touch the drive until you've got a good cable and a stable connection. Every failed mount attempt can trigger another controller crash. Don't run First Aid, don't let Disk Utility \"repair\" anything, and definitely don't let Windows format it if it pops up that dialog. Get a stable connection first, image the drive with ddrescue if you can, and then reach for recovery tools."
},
{
"$type": "blog.pckt.block.horizontalRule"
},
{
"$type": "blog.pckt.block.heading",
"level": 2,
"plaintext": "The Firmware Connection"
},
{
"$type": "blog.pckt.block.text",
"plaintext": "After recovering the data, I checked Crucial's firmware update tool (Crucial Storage Executive, Windows only). Both the X9 Pro and X10 Pro were on outdated firmware — and interestingly, both were on the same firmware branch. The update release notes included some suspiciously on-the-nose fixes:"
},
{
"$type": "blog.pckt.block.bulletList",
"content": [
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "Improved resiliency during error handling"
}
]
},
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "Improved low power mode behavior"
}
]
},
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "Improved background scan efficiency"
}
]
}
]
},
{
"$type": "blog.pckt.block.text",
"plaintext": "That maps almost perfectly to what I had experienced. The drives were likely hitting a firmware bug in their power/error handling that got triggered by something in that macOS update — possibly related to APFS encryption metadata reads, sleep/wake behavior, or USB power negotiation. Combined with a marginal cable, it was enough to corrupt or destabilize the APFS container metadata without actually killing the underlying hardware."
},
{
"$type": "blog.pckt.block.text",
"plaintext": "After updating firmware on both drives, I fully erased and repartitioned them, recreated fresh APFS volumes, verified the filesystems, and stress tested them. Both are working fine now."
},
{
"$type": "blog.pckt.block.horizontalRule"
},
{
"$type": "blog.pckt.block.heading",
"level": 2,
"plaintext": "What I Actually Think Happened"
},
{
"$type": "blog.pckt.block.text",
"plaintext": "This wasn't simple hardware failure. My theory is that it was a perfect storm:"
},
{
"$type": "blog.pckt.block.bulletList",
"content": [
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "A macOS update changed something in APFS encryption or USB power behavior"
}
]
},
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "Crucial's firmware had a bug in low-power/error-handling that made the bridge chipset unstable under those conditions"
}
]
},
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "A marginal USB-C cable provided just enough signal degradation to push the whole thing over the edge"
}
]
},
{
"$type": "blog.pckt.block.listItem",
"content": [
{
"$type": "blog.pckt.block.text",
"plaintext": "Both drives were on the same firmware branch, which is why they failed identically"
}
]
}
]
},
{
"$type": "blog.pckt.block.text",
"plaintext": "The NAND was fine. The hardware was fine. The data was fine. It was the stack of software and firmware layers on top of it that fell apart."
},
{
"$type": "blog.pckt.block.horizontalRule"
},
{
"$type": "blog.pckt.block.heading",
"level": 2,
"plaintext": "The Bigger Takeaway"
},
{
"$type": "blog.pckt.block.text",
"plaintext": "A portable SSD today isn't just \"a disk.\" It's NAND flash, a controller, USB bridge firmware, power management, USB-C signaling, APFS, encryption, and OS driver behavior — all stacked on top of each other. Any weak link in that chain can create chaos, and troubleshooting it means thinking about all those layers at once rather than just assuming the hardware died."
},
{
"$type": "blog.pckt.block.text",
"plaintext": "This whole experience pushed me toward cleaning up my storage architecture: better backups, more reliance on dedicated NAS infrastructure, and less dependence on fully encrypted portable SSDs as primary storage. If it's important enough to encrypt, it's important enough to have a second copy somewhere."
},
{
"$type": "blog.pckt.block.text",
"plaintext": "Also, I now have a small bag of \"known-good infrastructure cables\" that are no longer allowed to disappear into the random cable drawer."
},
{
"$type": "blog.pckt.block.horizontalRule"
},
{
"$type": "blog.pckt.block.text",
"facets": [
{
"index": {
"byteEnd": 89,
"byteStart": 0
},
"features": [
{
"$type": "blog.pckt.richtext.facet#italic"
}
]
},
{
"index": {
"byteEnd": 97,
"byteStart": 89
},
"features": [
{
"$type": "blog.pckt.richtext.facet#code"
}
]
},
{
"index": {
"byteEnd": 100,
"byteStart": 97
},
"features": [
{
"$type": "blog.pckt.richtext.facet#italic"
}
]
},
{
"index": {
"byteEnd": 103,
"byteStart": 100
},
"features": [
{
"$type": "blog.pckt.richtext.facet#code"
}
]
},
{
"index": {
"byteEnd": 106,
"byteStart": 103
},
"features": [
{
"$type": "blog.pckt.richtext.facet#italic"
}
]
},
{
"index": {
"byteEnd": 115,
"byteStart": 106
},
"features": [
{
"$type": "blog.pckt.richtext.facet#code"
}
]
},
{
"index": {
"byteEnd": 132,
"byteStart": 115
},
"features": [
{
"$type": "blog.pckt.richtext.facet#italic"
}
]
}
],
"plaintext": "Tools used: R-Studio (data recovery), Crucial Storage Executive (firmware update), macOS diskutil / gpt / fsck_apfs for diagnostics."
}
]
},
"updatedAt": "2026-05-08T21:04:58+00:00",
"description": "A couple years ago, after a macOS update I honestly can't remember anymore, two of my external SSDs became unreadable almost at the same time. Not one — two. Both encrypted APFS volumes. Both completely unreachable. I assumed the worst, threw them in a drawer, and moved on. Fast forward to now, where SSD prices are painful enough that just replace them felt a lot less appealing than it used to. Since both drives had failed in basically the same way, I figured it was worth taking one more look be...",
"publishedAt": "2026-05-08T21:02:27+00:00",
"textContent": "A couple years ago, after a macOS update I honestly can't remember anymore, two of my external SSDs became unreadable almost at the same time. Not one — two. Both encrypted APFS volumes. Both completely unreachable.\nI assumed the worst, threw them in a drawer, and moved on.\nFast forward to now, where SSD prices are painful enough that \"just replace them\" felt a lot less appealing than it used to. Since both drives had failed in basically the same way, I figured it was worth taking one more look before writing them off.\nThat turned out to be the right call.\nThe Setup\nOne was a 4TB Crucial X9 Pro. The other was a 2TB Crucial X10 Pro. Both had been formatted as encrypted APFS volumes on macOS and had been rock solid — until they weren't. After that mystery macOS update, both started behaving almost identically:\nAPFS containers unavailable\nIntermittent I/O errors\nDrives disappearing and reappearing from diskutil list\nFailed filesystem checks\nEventually, drives that wouldn't mount at all\nAt the time, two drives going down simultaneously felt like a hardware fluke or just bad luck. In hindsight, that should have been the first clue something else was going on.\nThe First Clue: The Cable\nWhen I pulled the drives back out and started digging in, the first thing I noticed was that swapping from a generic USB-C cable to a proper Thunderbolt 4 cable made a dramatic difference almost immediately. The devices stopped randomly disconnecting, the GPT partition tables became readable, and recovery tools could actually scan the APFS containers without the drives vanishing mid-scan.\nThat alone was telling. High-speed NVMe USB enclosures are surprisingly sensitive to cable quality — USB signaling integrity matters a lot more than most people expect, especially on Apple Silicon Macs with APFS-encrypted volumes doing heavy metadata reads during mount attempts. A marginal cable can cause the bridge chipset to choke right at the worst possible moment, and macOS interprets that as \"no filesystem here\" rather than \"the connection just hiccuped.\"\nA run of sudo gpt -r show /dev/disk6 with the better cable confirmed the APFS partition was actually still there — the GPT was intact, the APFS partition entry was intact, and the data was almost certainly still sitting on the NAND. The drive wasn't dead. It had just been getting knocked offline every time macOS tried to read the encrypted APFS metadata over a flaky connection.\nRecovery\nWith a stable connection, I ran R-Studio against both drives. It recognized the encrypted APFS containers, accepted the passwords, and successfully recovered the directory structures and data from both.\nIf you're in a similar situation, the important thing to know is: don't touch the drive until you've got a good cable and a stable connection. Every failed mount attempt can trigger another controller crash. Don't run First Aid, don't let Disk Utility \"repair\" anything, and definitely don't let Windows format it if it pops up that dialog. Get a stable connection first, image the drive with ddrescue if you can, and then reach for recovery tools.\nThe Firmware Connection\nAfter recovering the data, I checked Crucial's firmware update tool (Crucial Storage Executive, Windows only). Both the X9 Pro and X10 Pro were on outdated firmware — and interestingly, both were on the same firmware branch. The update release notes included some suspiciously on-the-nose fixes:\nImproved resiliency during error handling\nImproved low power mode behavior\nImproved background scan efficiency\nThat maps almost perfectly to what I had experienced. The drives were likely hitting a firmware bug in their power/error handling that got triggered by something in that macOS update — possibly related to APFS encryption metadata reads, sleep/wake behavior, or USB power negotiation. Combined with a marginal cable, it was enough to corrupt or destabilize the APFS container metadata without actually killing the underlying hardware.\nAfter updating firmware on both drives, I fully erased and repartitioned them, recreated fresh APFS volumes, verified the filesystems, and stress tested them. Both are working fine now.\nWhat I Actually Think Happened\nThis wasn't simple hardware failure. My theory is that it was a perfect storm:\nA macOS update changed something in APFS encryption or USB power behavior\nCrucial's firmware had a bug in low-power/error-handling that made the bridge chipset unstable under those conditions\nA marginal USB-C cable provided just enough signal degradation to push the whole thing over the edge\nBoth drives were on the same firmware branch, which is why they failed identically\nThe NAND was fine. The hardware was fine. The data was fine. It was the stack of software and firmware layers on top of it that fell apart.\nThe Bigger Takeaway\nA portable SSD today isn't just \"a disk.\" It's NAND flash, a controller, USB bridge firmware, power management, USB-C signaling, APFS, encryption, and OS driver behavior — all stacked on top of each other. Any weak link in that chain can create chaos, and troubleshooting it means thinking about all those layers at once rather than just assuming the hardware died.\nThis whole experience pushed me toward cleaning up my storage architecture: better backups, more reliance on dedicated NAS infrastructure, and less dependence on fully encrypted portable SSDs as primary storage. If it's important enough to encrypt, it's important enough to have a second copy somewhere.\nAlso, I now have a small bag of \"known-good infrastructure cables\" that are no longer allowed to disappear into the random cable drawer.\nTools used: R-Studio (data recovery), Crucial Storage Executive (firmware update), macOS diskutil / gpt / fsck_apfs for diagnostics."
}