Her G-Drive Mobile was mid-save when disaster struck: "Photoshop crashed and must have ejected the disk", and now, though it "audibly starts up and lights up", it "won't mount or show up at all in Disk Utility" — indeed "Disk Utility often crashes when the drive is plugged in". After an NVRAM reset she was "prompted for the encryption password (which usually is saved in Keychain so not required)", but it "still fails to mount". An unclean ejection mid-write corrupted the volume's structures — and the sudden password prompt is a consequence of that corruption, not evidence the encryption itself has failed.
| Media | 2TB G-Drive Mobile USB-C external, encrypted and normally unlocked automatically via macOS Keychain — abruptly ejected mid-write, now failing to mount and crashing Disk Utility |
| Reported situation | Drive ejected uncleanly when Photoshop crashed during a save · drive powers and lights but does not mount · Disk Utility frequently crashing when the drive is connected · encryption password prompted after an NVRAM reset, where Keychain usually supplies it silently · mounting still failing after the prompt |
| Fault class | Filesystem structure corruption from an interrupted write on an encrypted volume — the encryption intact and the password valid, with the damage in the volume structures the system reads after unlocking; physical health to be confirmed |
| Equipment used | Drive imaged under a hardware write-blocker before interpretation, with the encryption preserved as-is · physical health checked on PC-3000 UDMA, imaged on DeepSpar Disk Imager if the mid-write interruption left bad sectors · the encrypted volume unlocked with the owner's password against the image, never the original · APFS or HFS+ structures parsed from the decrypted image in R-Studio, backup copies located and rebuilt · recovered files validated by rendering |
An ejection during a write is exactly when filesystem damage happens. Saving a file means updating the volume's structures, and cutting power or connection mid-update leaves those structures half-written and internally inconsistent. That the disaster struck during a Photoshop save is the mechanism precisely: the drive was writing when it was pulled, and the interrupted write corrupted the bookkeeping that the system needs to mount the volume.
Disk Utility crashing on connection is a strong sign of structure corruption, not drive death. When the tool that reads a volume's structures repeatedly crashes trying to parse them, it is usually because those structures are damaged badly enough to defeat the parser. That is consistent with an interrupted-write fault and, importantly, distinct from a mechanically dead drive — this one powers, lights, and gets far enough to make Disk Utility choke on its contents.
The password prompt is the detail most likely to mislead, and it is worth reassuring her about. Her encryption password normally lives in Keychain and unlocks the drive silently; the NVRAM reset cleared that saved credential, which is why she was suddenly asked for it. Being prompted does not mean the encryption broke — it means the automatic unlock was reset. Her password is still valid. That it then still failed to mount points the finger at the corrupted volume structures the system reads after unlocking, not at the encryption layer itself.
The two problems are separate, and separating them is the key. There is an encryption layer, which is fine and opens with her password, and beneath it a filesystem whose structures are damaged. The drive fails to mount because after unlocking successfully, the system cannot make sense of the corrupted structures inside. Recovery unlocks the encryption and then rebuilds the filesystem behind it — two distinct steps, both necessary.
Everything is done on an image, which protects a delicate situation. The drive is imaged first, the encryption preserved, and the unlock and reconstruction performed against the decrypted image rather than the original — so no repair attempt writes to a volume that is already structurally fragile, and nothing forecloses a second approach. Her password is required for this, which is why an encrypted drive's recovery depends on the owner still having it.
Physical health is confirmed because the interruption could have left marks. A drive pulled mid-write is usually only logically damaged, but the abrupt stop can occasionally leave bad sectors, so the drive's condition is checked at the outset and imaging adapted if needed — the honest prognosis resting on logical-only versus physical-underneath, established before the work.
The drive was imaged under a hardware write-blocker with its encryption preserved, and its physical health checked on PC-3000 UDMA, imaged on DeepSpar Disk Imager where the interruption had left bad sectors. The encrypted volume was unlocked with the owner's password against the image, never the original, and the APFS/HFS+ structures parsed from the decrypted image in R-Studio, backup copies located and rebuilt. Recovered files were validated by rendering.
Encryption preserved and unlocked against the image, the corrupted filesystem rebuilt from its backup copies, and the files returned. The assessment is free and the quote is a single fixed figure inclusive of VAT; if the data cannot be recovered, there is nothing to pay. The decode: the crash ejected the drive mid-write and broke the volume's structures — the password prompt was just the NVRAM reset clearing your saved key, not the encryption failing. Unlock it and rebuild the structures behind it, and your work comes back.
Don't let Disk Utility "First Aid," erase, or reformat the drive — on an encrypted volume with damaged structures, those write to the disk and can bury recoverable files. Being newly prompted for a password you thought was automatic usually means a reset cleared it from Keychain, not that the encryption broke, so keep that password safe — recovery of an encrypted drive depends on it. Stop reconnecting the drive to retry, and let recovery unlock and rebuild from an image.
Our case files are written up from genuine enquiries our lab has handled for customers across Staines, Surrey and the surrounding area, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery approach our engineers apply to that fault, using the equipment listed.
Free diagnostic, fixed quote, no fix no fee — start now or call the freephone.