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...
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

  • For me, ecryptfs-mount-private, possibly having to be preceded by sudo encryptfs-mount-private, sudo encryptfs-recover-private, ecryptfs-stat or ecryptfs-manager magically worked... Mar 12, 2021 at 10:18

2 Answers 2


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.



# 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


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

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:
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.

  • 7
    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, 2018 at 22:09
  • 2
    @ulkas Any idea why this works?
    – Turion
    Nov 27, 2018 at 8:57
  • 2
    @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, 2018 at 9:44
  • 3
    keyctl link @u @s was a much simple solution for me. Credits go here: bugs.debian.org/cgi-bin/bugreport.cgi?bug=870126
    – sup
    Jul 21, 2019 at 11:15
  • 1
    @sup Your comment was the correct answer for me: keyctl link @u @s then ecryptfs-mount-private worked
    – Eduardo
    Apr 21, 2020 at 13:01

To future viewers of this Q&A: the same apparent symptom may be caused by different underlying reasons. The symptom looks like:

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...
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].

In my case, this answer held the key to the solution. The problem was that I was trying to do everything remotely over SSH in a Tmux session, which somehow messes up with user session keyrings.

The aforementioned answer suggests to comment a certain line in /etc/pam.d/sshd out and try again in a new session, but that did not work for me. The simple workaround that worked instead was to do it on location, avoiding SSH and Tmux altogether.


Inspired heavily by this answer, I was able to mount my old encrypted home, while connected over SSH in a Tmux session, using the following approach:

Assuming that the old root partition (where /home/ used to be) is mounted at /mnt/oldroot/, and the old username is olduser:

mkdir -p ~/.ecryptfs
echo "/mnt/oldroot/home/.ecryptfs/olduser/.Private /mnt/oldroot/home/olduser ecryptfs" > ~/.ecryptfs/oldhome.conf
cp -a /mnt/oldroot/home/.ecryptfs/olduser/.ecryptfs/Private.sig ~/.ecryptfs/oldhome.sig

# This will prompt for the old login password:
ecryptfs-insert-wrapped-passphrase-into-keyring /mnt/oldroot/home/.ecryptfs/olduser/.ecryptfs/wrapped-passphrase

# This will mount the old decrypted home contents over /mnt/oldroot/home/olduser:
mount.ecryptfs_private oldhome

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .