Comment 9 for bug 455709

Solved.

The problem is 50% a minor flaw in mount.ecryptfs and 50% user error.

* mount.ecryptfs: As of ecryptfs-utils version 81-0ubuntu3, if you mount interactively (i.e. mount -t ecryptfs /path1/private /path2/public) and ask to use FNEK, mount.ecryptfs will suggest the wrong key when it prompts you for the FNEK key signature. Everyone assumes that the suggestion must be right, chooses the default, and gets an incorrectly mounted directory.

Interestingly, the mount does not fail, and the filenames are correct, even though the wrong FNEK key was used. It's just that none of the files are accessible. If the mount had failed or the filenames were wrong, then the users would have guessed (sooner or later) that something was wrong with the FNEK key, tried switching the keys around, and gotten a correctly mounted directory. Instead, you get bug reports.

Another interesting thing about mount.ecryptfs is that it effectively ignores the ecryptfs_sig option. It always inserts its own ecryptfs_sig option derived from looking at your passphrase, thus masking the ecryptfs_sig explicitly provided by the user. This is another reason why users get confused: if mount.ecryptfs blindly used the ecryptfs_sig specified by the user, then the whole mount would fail if the keys got reversed. Instead, it looks like the keys were correct, but something went wrong internally.

* user error: Your instructions in #3 are correct. However neither Martin nor I followed them perfectly, because we had both tried to mount interactively before ever coming here to report a bug. We already "knew" which key was for content and which key was for FNEK, so being smart guys we skipped the SIG1=$(head...) and SIG2=$(tail...) steps and just put in the keys by hand. Given that mount.ecryptfs doesn't report a failure when you get the keys reversed, I think this is probably a common problem.

My suggestions:

1) Correct mount.ecryptfs to suggest the correct key. This will make most of the "I can't recover my home directory" bug reports and help requests disappear.

2) Have mount.ecryptfs fail or issue a warning on stderr if the ecryptfs_sig option it derives from the passphrase conflicts with one explicitly provided as a mount option.

3) Prominently post instructions for recovering your home directory, in which you warn the user not to trust the suggested FNEK signature.

I have noticed that some of the recovery instructions you have posted (on your blog and in Linux Magazine) use chroot and ecryptfs-mount-private, and therefore rely on having the entire original filesystem available in a healthy state. However, I have also noticed a lot of help requests from people who have a backup of the .Private directory and nothing else. In fact, I think this is by far the most likely scenario for anyone trying to recover a home directory. (If the original system is in a healthy state, you could just boot it.) Reading these help requests it seems that most people try the chroot + ecryptfs-mount-private approach, and when that fails they usually come to the conclusion that their filenames are unrecoverable, say some bad things about ecryptfs, and give up. If you replaced the chroot + ecryptfs-mount-private instructions with instructions for root to mount -t ecryptfs (and be careful about the FNEK signature), these users would be able to recover their data the first time around.