My client originally complained that he'd get a kernel panic (KP) when logging into his main account on his machine, but he could log in fine to a secondary account -- although he couldn't see the contents of his main home folder from there. At first I thought, "Ok, he's got a bad startup item and can't see the contents of the other folder due to not having permission." The machine still KP'd even when booting in safe mode, so I booted to single user mode and discovered his main account's home folder was actually empty except for a .autodiskmount file. Since a startup item wasn't to blame and the home folder wasn't being populated with items from the default user template, I figured he was using FileVault and his home sparseimage had been deleted. Turned out his original home folder had somehow been renamed to .shortusername, rendering it invisible and a new one had been created which only had root permissions ... and his sparseimage was safely tucked inside his original home folder (phew).
Read the rest to see how I managed to recover the sparseimage. Note that none of the following involves circumventing FileVault: though not specifically detailed, the encryption password was requested and provided at the appropriate times during the recovery process.
Easy fix? Well, after getting rid of the new folder and removing the period from his old home, the machine would still KP right after logging into the main account. Logged into the secondary account and tried to mount the sparseimage manually and got a message from the DiskImageHelper application that there were no mountable file systems in the image. Not sure why it didn't just KP when logged into this account, but that seems to be beside the point. Now the fun begins.
I booted to my FireWire diag HD and when trying to mount the disk image there, the machine would KP as soon as I entered his password. I tried mounting the image via the hdiutil attach imagename command which, at least, gracefully failed instead of causing the machine to arf. I even tried using Mount, a neat old utility made by Scott Houchin, but no luck. Since hdiutil attach failed without actually killing the kernel, I decided to try running hdiutil convert shortusername.sparseimage -format UDRW -o shortusername.dmg to see if that would produce a mountable image. The conversion actually finished without error, but the directory on his orginal 6GB sparseimage was damaged such that the conversion process produced a 26GB image! Worse yet, the resulting image would also KP the machine when double-clicked. Now that encryption (hopefully) was not an obstacle any more, I thought my only option was going to be to drag the dmg onto File Juicer (a fantastic little app) and scrounge out what images, movies and text documents I could.
However, I decided to see what Disk Utiliy could do first -- since it's the only directory repair utility I know of that will operate directly on images before they're mounted -- so I dragged the image to the drive list container. A Verify showed severe damage to the directory inside the image, and a Repair tried to mount the image which again KP'd the machine. Just to see what would happen, I created a new blank sparseimage and then used the Restore function in Disk Utility to try to copy from the damaged image to the new image. This actually worked up to a point: the process died with an error partway through copying the user's Documents folder although what was copied appeared to be free of corruption. This was encouraging.
I noticed that when running the Verify in First Aid, a greyed-out hard drive icon would briefly appear under the disc image icon in the drive list and then disappear. After a short bit of experimenting, I discovered that if I hit the Verify button and then immediately hit Stop Verify, the process would stymie and leave the greyed-out disc icon under the image. This is important: this greyed-out icon represents the image's volume in some sort of half-mounted state. So I ran DiskWarrior, and the volume showed up in the list of available volumes to rebuild! Unfortunately, DiskWarrior found over 12,000 crosslinked files and was taking forever to finish the directory scan. From experience I've found that DiskWarrior usually has problems fixing volumes with more than a couple crosslinked files, so I stopped that.
Next I tried Data Rescue, and that appeared to be thoroughly successful -- I got the entire folder structure of the original home folder and with a random sampling, the files appear to be intact.
So to summarize:
- If you have an encrypted image which won't mount or causes a KP after entering the password key, the first thing to try (if Disk Utility won't repair it) is to get it into an unencrypted state by launching Terminal and typing hdutil convert sourceimage.type -format UDRW -o targetimage.dmg. If the converted image still won't mount, this will at least allow utilities like File Juicer or PhotoRescue to work on it. (If anyone knows of other repair or recovery utilities that will work directly on disc images without mounting them, please share.)
- If you need more than image or text files recovered, try creating a new image -- either with DiskUtility or with hdiutil create -type SPARSE -size 50g -fs HFS+ growableimage, and then use the Restore tab in Disk Utility to try to copy the contents from the damaged image to the new one. Note: you have to mount the new image so you can drag the disc icon to the Destination field).
- If no other utilities work, then try selecting the damaged disc image in Disk Utility, select the First Aid tab, then try hitting the Verify button and immediately hitt the Stop Verify button, and see if you can get that ghost volume to stick. Then possibly Disk Warrior or other recovery utilities can save the day.

