Data Recovery Case File · Mac & Apple Ecosystem · The Key Exists, the Lock Is Damaged
FileVault Corrupted: the Password Is Right and Fails
His enquiry described a situation that sounds identical to a lost password and is fundamentally different from it. A Mac mini: "FileVault has corrupted and it has locked my drive so I cannot log in with my password. Apple support have not been able to fix it. Can you fix it?" He knows his password. He is entering the right one. The machine is refusing it. Elsewhere in this archive there are cases where the credential itself is gone, and those end in an honest wall — encryption without a lawful key is mathematics, not a lock to be picked. This is the other situation, and it is genuinely more hopeful: the key material exists and the owner holds what unlocks it. What has failed is the structure that the password operates on. A damaged lock is a different problem from a missing key.
| Media | Mac mini internal drive with full-disk encryption enabled — owner's password not accepted; volume inaccessible; manufacturer support unable to resolve |
| Reported situation | Encryption enabled and password known · correct credential rejected at login · manufacturer support exhausted without resolution · in-person attendance offered; turnaround and cost sought |
| Fault class | Damage to encryption metadata rather than absence of a credential — key material present and owner-held; recovery contingent on locating intact metadata copies |
| Equipment used | Volume imaged write-blocked before any attempt · encryption metadata located and assessed on the image, including redundant copies · unwrapping performed strictly with the owner's own password (Passware Kit Forensic) · volume rebuilt from the copy and verified by opening |
The decode: what the password actually unlocks, and why redundancy helps
How the password relates to the encryption: the distinction that makes this case what it is. A user's password does not encrypt the disk directly. The volume is encrypted with a key generated when protection was switched on, and that key is stored on the disk itself in wrapped form — protected by structures the password unwraps. So there are two things involved: the credential, which he has, and the metadata holding the wrapped key, which lives on the volume and can be damaged like anything else stored there. When that metadata is corrupt, the correct password has nothing valid to operate on, and the machine reports a failed unlock — indistinguishable, from the user's side, from typing the wrong password.
Why that is a better position than a lost key: because the missing ingredient is not the secret. Where a credential is genuinely unknown, no bench can help and this archive says so. Here the secret is present and lawfully held; what has to be found is an intact copy of the structure it unwraps.
Why intact copies often exist: the hopeful part, and the reason this is worth attempting. Encryption metadata of this kind is not stored once and hoped for. Volumes of this design maintain the relevant structures in more than one location precisely because losing them would be catastrophic, and damage is frequently localised to one copy. Working on a full image of the disk, those locations can be examined individually, an undamaged copy identified, and the wrapped key unwrapped using his own password — after which the volume decrypts normally and its contents are recovered as usual. That is ordinary, careful work rather than anything exotic, and it is exactly the kind of examination that cannot be done through a login screen, which is why manufacturer support reached its limit.
The honest limit: stated because it must be. If every copy of the metadata is destroyed and no recovery key exists anywhere, then the wrapped key cannot be unwrapped and the data is beyond reach — for anyone, at any price. That possibility is established by examination and reported plainly rather than worked around. He should also locate his recovery key if he can, since it provides an independent route.
What must not happen first: the standard next suggestion after support runs out is to erase and reinstall. That writes over the very structures a recovery would rebuild from, and on an encrypted volume it is final. Nothing should be reinstalled, erased or "repaired" before the disk is imaged.
On the bench
The drive was imaged write-blocked before any unlock was attempted, because every subsequent step needed to happen against a copy — and because an erase or reinstall at this point would have been irreversible. On the image the encryption metadata was located and assessed, including the redundant copies the volume design maintains, and an intact structure was identified. Unwrapping ran strictly against his own password through Passware Kit Forensic — the only kind of credential this bench turns — after which the volume decrypted and was rebuilt from the copy. His files were verified by opening and delivered on fresh media, with the position and its limits documented in writing throughout.
The outcome
The damaged metadata bypassed via an intact copy, the volume unwrapped with the owner's own password and the contents verified and delivered. Free assessment, one fixed written figure including VAT; where a drive has to be opened or a chip removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone whose correct password is being refused: a password does not encrypt the disk directly — it unwraps a key stored on the volume, so damage to that stored structure makes the right password fail in a way that looks exactly like the wrong one; that is a better position than a lost credential, because the secret is present and only the structure needs finding; volumes of this design keep more than one copy of it, and damage is often localised; and do not let anything erase or reinstall before the disk is imaged, because on an encrypted volume that step is final.
Correct password refused on an encrypted Mac
Don't erase or reinstall — that's the usual next suggestion once support runs out, and on an encrypted volume it writes over the structures a recovery rebuilds from, permanently. Understand why the right password can fail: your password doesn't encrypt the disk directly, it unwraps a key stored on the volume itself, so if that stored structure is damaged the correct credential has nothing valid to work on and the machine reports a failed unlock exactly as if you'd mistyped. That's a much better position than a genuinely lost password, because the secret exists and you hold it. Volumes of this design keep more than one copy of that structure, and damage is often confined to one, so an intact copy can frequently be found on a full image of the disk. Meanwhile, dig out your recovery key if you have one — it's an independent route in. And stop repeated login attempts.
Don't let anyone reinstall — call Leeds Data Recovery on 0113 322 3083; imaged write-blocked first, redundant metadata copies examined, unwrapped with your own password only.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.