mount: No such file or directory with encrypted recovery

I found that running sudo bash and then running ecryptfs-recover-private as root (rather than via sudo) worked. Not sure why it should be any different.

Edit:

TL;DR:

# ecryptfs-unwrap-passphrase /mnt/crypt/.ecryptfs/user/.ecryptfs/wrapped-passphrase - | ecryptfs-add-passphrase --fnek -
    < Type your login password here >
Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring

You will not see a prompt and must type your login password, blind, into the above command.

Replace the aaaaaaaaaaaaaaaa and bbbbbbbbbbbbbbbb below with the hex signatures between brackets from the output above, in order:

# mount -i -t ecryptfs -o ecryptfs_sig=aaaaaaaaaaaaaaaa,ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /mnt/crypt/.ecryptfs/user/.Private /mnt/plain

Preliminaries

It turns out just running as root did not work reliably for me; sometimes it did, sometimes it didn't. Basically, ecryptfs seems buggy and quite user-unfriendly, often confusing login passwords and mount passphrases. After going down a deep, dark rabbit hole, I have some tips that should help. These notes are for Ubuntu 17.10, ecryptfs-utils 111-0, and you should become root before starting. I assume you want to mount your home directory from /mnt/crypt (which should already be mounted) to /mnt/plain, and you should replace user with the username.

Start Easy

The first thing to try is:

# ecryptfs-recover-private /mnt/crypt/.ecryptfs/user/.Private

If this works, well, you're lucky. If not, it may give an error message from mount about no such file or directory. This is extremely misleading: what it really means is your mount passphrase is wrong or missing.

Get The Signatures

Here is the important part: we need to verify ecryptfs is really trying the right mount passphrase(s). The passphrases must be loaded into the Linux kernel before ecryptfs can mount your filesystem. ecryptfs asks the kernel for them by their signature. The signature is a 16-byte hex value (and is not cryptographically sensitive). You can find the passphrase signatures ecryptfs is expecting:

# cat /mnt/crypt/.ecryptfs/user/.ecryptfs/Private.sig
aaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbb

Remember these. The goal is to get passphrases with these signatures loaded into the kernel and then tell ecryptfs to use them. The first signature (aaaaaaaaaaaaaaaa) is for the data, and the second (bbbbbbbbbbbbbbbb) is the FileName Encryption Key (FNEK).

Get the mount passphrase

This command will ask you for you login password (with a misleading prompt), and output your mount passphrase:

# ecryptfs-unwrap-passphrase /mnt/crypt/.ecryptfs/user/.ecryptfs/wrapped-passphrase

Copy this but be careful!!, as this is extremely cryptographically sensitive, the keys to the kingdom.

Try an interactive mount

The next thing to try is:

# mount -t ecryptfs /mnt/crypt/.ecryptfs/user/.Private /mnt/plain

The crucial thing here is that mount needs your (super-sensitive) mount passphrase that we just copied (not your login password).

This will ask you some questions, and you can accept the defaults except say yes to Enable filename encryption. It may give you a warning and ask to cache the signatures; you can say yes to both, but do double-check that you've got the right mount passphrase.

You will see the options that mount has decided to try for you:

Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=aaaaaaaaaaaaaaaa
Mounted eCryptfs

If the signatures are wrong (don't match what you got from Private.sig), the mount won't work.

...but it will very unhelpfully report that it did. You will have to do an ls /mnt/plain and cat a file to make sure. At this point you can also look in /var/log/syslog and verify that ecryptfs is looking for the same signatures we are.

There are clearly two serious issues with ecryptfs here, and we have to work around them.

Load the keys into the kernel

If the interactive mount didn't help, we have to load the keys into the kernel ourselves and manually specify them in the mount options.

# ecryptfs-add-passphrase --fnek

And paste in your (super-senstive) mount passphrase copied from above. This should output:

Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring

Mount manually

Now the passphrases are loaded into the kernel, and we just need to tell mount to use them:

# umount /mnt/plain
# mount -i -t ecryptfs -o ecryptfs_sig=aaaaaaaaaaaaaaaa,ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /mnt/crypt/.ecryptfs/user/.Private /mnt/plain

You'll notice the options are similar to what the interactive mount printed out, except we're manually telling ecryptfs what's up.

Hopefully this works. If not, you can check that the keys are loaded into the kernel with the correct signatures using keyctl list @u, which should print out at least the two signatures you're expecting.