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
Best Answer
I found that running
sudo bash
and then runningecryptfs-recover-private
as root (rather than via sudo) worked. Not sure why it should be any different.Edit:
TL;DR:
You will not see a prompt and must type your login password, blind, into the above command.
Replace the
aaaaaaaaaaaaaaaa
andbbbbbbbbbbbbbbbb
below with the hex signatures between brackets from the output above, in order: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 replaceuser
with the username.Start Easy
The first thing to try is:
If this works, well, you're lucky. If not, it may give an error message from
mount
aboutno 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:
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:
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:
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: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.
And paste in your (super-senstive) mount passphrase copied from above. This should output:
Mount manually
Now the passphrases are loaded into the kernel, and we just need to tell mount to use them:
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.