After a bit of messing about, it turns out that there is a better compromise which doesn't seem to be clearly documented anywhere obvious, so I thought I'd share it here. I don't believe this is a duplicate but I'm happy to see this question closed if I've missed something.
The cost of the solution (which may be unacceptable to some) is that you need to sacrifice about 14G of your drive to a honeypot partition. The steps I took are:
Use Disk Utility to resize your boot partition to create at least 14.3G of free space at the end of the drive. If you've already enabled FileVault, I believe this means you're going to have to turn it off and wait for it to finish decrypting first.
Create an empty, Mac OS Extended, Journalled partition at the end of your drive filling the free space.
To make things look a bit more convincing, give your new partition a name that's more plausible than Macintosh HD (2) - I name mine after my host name.
Restart your computer and launch into recovery mode by holding down Cmd-R as the system boots.
Select reinstall OS from the recovery menu, and follow through with the install. Somewhere along the line you will get the option to select where to install the OS. You want to put it on the new partition, obviously. It should be just big enough to let you install Lion. If it isn't you're going to have to drop back out to the main recovery menu, fire up Disk Utility and resize the partitions again. This is a bit of crapshoot because you don't end up with as much free space as the specified size of the partition but you'll get there in the end.
Complete the installation of your new copy of Lion. You want to set this up as a honeypot, so:
- Enable automatic login that logs into a non-administrative account with the same username as you use on your main partition (for added plausibility)
- Make sure your admin account has a decent password to make it hard for the thief to mess with your tracking software if he finds it
- Don't hook anything up to iCloud - I'm assuming you're going to be using an alternative service like Undercover, Prey or LoJack to aid recovery, so it's just more potential exposure and best avoided.
- Install your tracking software of choice on the honeypot partition. I went with Undercover in the end because it's a one-off cost and Prey is written in bash
<shudder>.
Prevent corestoraged from trying to mount encrypted partitions on startup, thus blowing your cover:
sudo mkdir -p /System/Library/LaunchDaemons.Disabled
sudo mv /System/Library/LaunchDaemons/com.apple.corestorage.corestoraged.plist /System/Library/LaunchDaemons.Disabled/com.apple.corestorage.corestoraged.plist
(A bit of a hack, but it's only a honeypot. Hat tip to the contributors here )
- Reboot your system. You'll need to hold down alt/opt as the system boots to bring up the boot menu. Select your original main partition to boot into your main system.
- (Re)Enable FileVault for this partition and allow it to complete.
- Install your tracking software on this partition as well (this works fine for Undercover, which identifies machines by serial number of MAC address, so it doesn't care which partition you boot into)
- Set a firmware password. If you're on a pre-2011 mac this is only a token gesture, but I suppose every little helps. If you have a newer mac, this is a serious security measure, as the only options for circumventing it AFAIK are taking it to Apple or physically replacing a chip on the motherboard.
So now, if you power off your mac and boot it from cold, it will boot into the honeypot partition without even asking for a password. To an unsophisticated thief, it will look like they've got access to your machine just by rebooting it. There's a fighting chance that your tracking software will have a chance to file a report before the thief realises that something isn't quite right.
When you reboot your machine, you will have to remember to hold down the alt/option key to get into your proper system, at which point you will be prompted for a password to decrypt it. Assuming that you have the appropriate locking settings enabled for sensible security, your machine is tolerably secure against someone getting hold of sensitive private data.
If you have a recent mac with proper firmware protection, the thief will have an exceptionally difficult time using anything other than the honeypot partition, and will struggle to do anything particularly useful even with that, since he has no administrative rights. With any luck, by the time he's finished getting frustrated with it the police will already be knocking at his door :-)
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
Assuming that your disk is APFS formatted, run the following command in the Terminal:
Then you need to check if it lists "Type: iCloud Recovery User" and "iCloud Recovery External Key" - if that is the case, then your computer thinks the recovery key is stored in iCloud.
If you're worried that Apple somehow lost your key and need to verify that they still have it, you'll have to go through the actual recovery process to try unlocking your drive without your passphrase. That is the best test to see if everything is setup and working as it should, and that Apple has your key.