FileVault 2 uses the GeneratedUID user attribute to save who is permitted to unlock an encrypted volume. If the GeneratedUID of a user differs from what was generated (or pulled from LDAP) when FileVault 2 was enabled, the user will not be permitted to unlock the machine, as their account will appear to be unavailable at the EFI menu. Also, this causes the crash of System Preferences on their Mac whenever they try to access the Security & Privacy prefpane.
This problem arises when /usr/bin/mcxrefresh runs and pulls a null value or a value different than what is stored locally from LDAP (if the attribute isn't defined for the user in question or is defined incorrectly, respectively), overwriting the GeneratedUID stored locally (which is generated and only stored locally when FileVault 2 is enabled without a matching LDAP attribute).
In other words, if an apple-generateduid value exists in LDAP for a user and is mapped properly on the users Mac to the GeneratedUID attribute, FileVault 2 will not generate a new value, but will instead use the value stored in LDAP.
I was able to resolve this issue by adding an attribute called apple-generateduid to the LDAP entry of any user experiencing this issue. I could generate a random value for this attribute in Python by running the following one-liner from my terminal:
python -c 'import uuid; print str(uuid.uuid4()).upper();'
This isn't the only step, however. You must also add a mapping for this attribute on the client side. This is easily done using the following steps:
- Open System Preferences.
- Click Users & Groups.
- Click Login Options.
- Click on the Unlock Icon.
- Under Network Account Server, click Edit.
- Click to highlight your directory server.
- Under Services, double-click on your directory service (in my case, it was LDAPv3)
- In the window that slides open, highlight your configuration name, and then click the Edit... button.
- Under Search & Mappings scroll down and single-click on Users to highlight it.
- Click the Add button (the left one).
- Choose GeneratedUID from the list of available Attribute Types.
- In the right column, click the Add button, and type
apple-generateduid. Click OK to save the changes until you're back at the main System Preferences dialog.
- At this point a mapping from GeneratedUID to
apple-generateduid has been created. Now when OS X looks up the GeneratedUID value it will get the value of apple-generateduid from the user in questions LDAP entry.
Finally, it's important that the locally stored value of GeneratedUID and value stored on LDAP match. Run the following command and make sure the two GeneratedUID values match:
dscl /Search search /Users GeneratedUID $(dscl . read /Users/$(echo $USER) GeneratedUID | cut -d " " -f2)
Just had this happen to me, error -69842 on a FileVault encrypted mid-2013 MacBook Air, and I spent a fair bit of time on it the last few days. I tried Recovery Mode, Target Disk Mode, fsck_hfs, and DiskWarrior with no luck. Disk Utility gave me an error 'Invalid thread record' or something like that. DiskWarrior indicated it was a 'disk hardware failure'. It was a corrupted FileVault volume no doubt.
I was finally able to get at my files by booting up in single-user mode. Hold CommandS while booting. You'll have to pick a user and enter your password, then it'll drop you to command line. The encrypted volume that would otherwise fail to mount with Disk Utility or 'diskutil coreStorage unlockVolume' will be already mounted in your Unix shell. Apparently single-user mode bypasses whatever filesystem check is failing when an error unlocking occurs. Perhaps this is because no fsck is being run, I'm not sure.
I was able to get my files off this way using a connected USB drive. Run mount -uw / && mkdir /Volumes/usb, then plug the USB in and do ls /dev/disk* to find the name. Mine was /dev/disk2s2, so mount_hfs /dev/disk2s2 /Volumes/usb and I had a way to copy files off. Use mount_msdos instead of mount_hfs if you formatted it for non-Mac use. I selectively copied user folders one thumbstick at a time, but if you have a large enough USB drive attached then just do a tar czpf /Volumes/usb/Users-backup.tgz /Users to get a copy of the entire /Users folder in tar-gzip format.
Recreating the FileVault volume is necessary. I did not find a way to repair it.
Best Answer
So it turns out you can ignore the shaking and select 'restart' after which the new password works. After logging in with it you'll be presented with another reset password screen but this one works.