8

I have destroyed my Mint Linux installation. I just wanted access to my remote storefront. So what happened was I was having trouble with ICEauthority file in my home directory. So following different directions on the internet I came to the conclusion that I could set the home directory recursively to chmod 755 to allow that file to work…eventually I ran into problems with the system loading. Eventually by setting the home directory to executable permission for root was I able to get read/write access…but then i reset my machine oh why oh why did i reset my machine!!! - now the system throws me the same error with ICEauthority but it never gets me into the OS because the disk is encrypted. Nothing I’ve tried seems to work and I don’t have the original mounting seed. I’ve also tried sudo ecryptfs-recover-private but my system then just says No such file or directory:

frankenmint@honeybadger /home $ sudo ecryptfs-recover-private
INFO: Searching for encrypted private directories (this might take a while)...
INFO: Found [/home/.ecryptfs/frankenmint/.Private].
Try to recover this directory? [Y/n]: y
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] y
INFO: Enter your LOGIN passphrase...
Passphrase: 
Inserted auth tok with sig [979c6cdf80d2e44d] into the user session keyring
mount: No such file or directory
ERROR: Failed to mount private data at [/tmp/ecryptfs.Hy3BV96c].

I’m really worried because I had important files on there that were stored on a virtual machine…If I could just get to those files then I would have no qualms nuking the setup and starting over

8

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.

  • 2
    there is a workaround when the ecryptfs-recover-private outputs a mount(2) error. try to run sudo ecryptfs-manager, press 4 (exit), then run again the original ecryptfs-recover-private. should work now – ulkas Nov 6 '18 at 22:09
  • @ulkas Any idea why this works? – Turion Nov 27 '18 at 8:57
  • 1
    @Turion i googled the solution out, so im not the inventor. my guess is there is a bug in the ecryptfs from some version up and calling the manager simply sets some variables which are later reused by the mount.any idea how to automatize this so i can mount my folders after each reboot ? – ulkas Dec 5 '18 at 9:44

protected by Community Oct 24 '18 at 0:03

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.