"mounting eCryptfs: [-2] No such file or directory" mount.ecryptfs default behavior is inconsistent with ecryptfs-mount-private, ecryptfs-migrate-home, etc.

Just an update, the above instructions don't let you actually read any of the files, it just shows you there names :)

Martin-

Okay, try this ...

ecryptfs-unwrap-passphrase /home/.ecryptfs/kirkland/.ecryptfs/wrapped-passphrase
(record this as your MOUNTPW)

keyctl clear @u
keyctl list @u
(should be empty)
ecryptfs-insert-wrapped-passphrase-into-keyring /home/.ecryptfs/kirkland/.ecryptfs/wrapped-passphrase
keyctl list @u
(should see 2 sigs, one for file contents, one for filenames)
SIG1=$(head -n1 /home/.ecryptfs/kirkland/.ecryptfs/Private.sig)
SIG2=$(tail -n1 /home/.ecryptfs/kirkland/.ecryptfs/Private.sig)
mount -t ecryptfs -o rw,relatime,ecryptfs_fnek_sig=<SIG2>,ecryptfs_sig=<SIG1>,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /home/.ecryptfs/kirkland/.Private /mnt
ls /mnt
cat /mnt/.profile

This is working for me... Can you give this a shot?

Note that we're using mount -t ecryptfs here, rather than mount.ecryptfs.

:-Dustin

Still doesn't work, with the same errors.

root@beuno-laptop:/mnt# mount -t ecryptfs -o rw,relatime,ecryptfs_fnek_sig=XXXXXXXXX,ecryptfs_sig=YYYYYYYYY,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /media/59619bec-a6cf-4fc1-9a7a-9a992cd31ce8/home/beuno/.Private /mnt/hdext
Passphrase:
Enable plaintext passthrough (y/n) [n]: n
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=a521ad46fa60c9c7
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=a521ad46fa60c9c7
Mounted eCryptfs
root@beuno-laptop:/mnt# ls hdext/
ls: cannot access hdext/Pictures: No such file or directory
ls: cannot access hdext/mysqlcc: No such file or directory
ls: cannot access hdext/installed-software: No such file or directory
ls: cannot access hdext/Videos: No such file or directory
ls: cannot access hdext/Ubuntu One: No such file or directory
ls: cannot access hdext/pentacorp: No such file or directory
ls: cannot access hdext/Desktop: No such file or directory
ls: cannot access hdext/agile_usability.pdf: No such file or directory
ls: cannot access hdext/Dropbox: No such file or directory
ls: cannot access hdext/martin: No such file or directory
ls: cannot access hdext/debian: No such file or directory

I wonder if there's anything odd with the passphrase. I can use either the output of ecryptfs-unwrap-passphrase or my users' log in password (which was the same one on that HD).

On Wed, Oct 21, 2009 at 8:00 AM, Martin Albisetti <email address hidden> wrote:
> I wonder if there's anything odd with the passphrase. I can use either the output of ecryptfs-unwrap-passphrase or my users' log in password (which was the same one on that HD).

Right, that's one of the things we need to "fix" in mount.ecryptfs.
If you pass the sig in on the command line, and that sig is already in
your keyring, you should *not* be prompted for the passphrase. This
confuses matters.

When you're prompted for the passphrase, you *must* put in the output
of the ecryptfs-unwrap-passphrase command. Otherwise, matters are
confused.

:-Dustin

Tried this, still nothing.

I get the same problem. Working with Jaunty amd64, my home directory mounts fine when it is all done automatically, but when I try to do it by hand (as root from the latest Jaunty LiveCD as part of a system diagnostic run), I get the results described in #4 above: Filenames decrypted properly, but "No such file or directory."

Note that mount.ecryptfs reports that it is doing the following:
"""
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=a521ad46fa60c9c7
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=a521ad46fa60c9c7
"""

I.e. it is using the *SAME* signature for both fnek and file contents. That should explain the symptoms.

The problem seems to be with the user utils. No matter what combination of command line options (mount -o ...) or interactive input I use, the fnek signature always gets used for both ecryptfs_fnek_sig and ecryptfs_sig.

Since I can mount my home directory automatically with no problems, it would seem that there a way of decrypting the files without going through the user tools. Is that the case? Can a workaround be built from that?

After much searching around, I found your article in Linux Magazine:
http://www.linux-mag.com/id/7568/3/

The instructions there work for me. So I have a workaround. On the other hand, in your article the chroot environment contains the entire original system. The original poster seems to only have a backup of /home. Can the method from your article be adjusted to mount a backup of /home only? What if the backup is on readonly media? (The chroot method failed for me when I tried to mount my backup readonly, but that was the entire filesystem, not just /home.)

I also notice that in the chroot environment I get the same errors as described in my previous post if I try to mount the home directory via mount -t ecryptfs (as root, by necessity) instead of via ecryptfs-mount-private (as the original user). Is the problem in the difference between mount.ecryptfs and mount.ecryptfs_private?

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

Correction to #7: I was using Karmic amd64 LiveCD, not Jaunty.

Adapted Dustin's instructions today as I needed something more automatic.

You can copy line-by-line to the terminal or save it and call it with bash or sh:

_______________________________________
ROOT=/home/.ecryptfs/$USER
TARGET=/mnt/$USER

# ROOT should be the parent of the .ecryptfs and .Private folders

sudo mkdir -p $TARGET
cd $ROOT

echo Type your password:
PASS=$(ecryptfs-unwrap-passphrase .ecryptfs/wrapped-passphrase | sed s/Passphrase:\ //)
SIG1=$(head -n1 .ecryptfs/Private.sig)
SIG2=$(tail -n1 .ecryptfs/Private.sig)

echo Passphrase:
echo $PASS
echo Signatures:
echo $SIG1
echo $SIG2

echo Should be empty:
sudo keyctl clear @u
sudo keyctl list @u

echo Do not type your anything:
echo $PASS | sudo ecryptfs-add-passphrase --fnek

echo Sould have signatures:
sudo keyctl list @u

echo Mounting $ROOT on $TARGET...
sudo mount -t ecryptfs -o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=yes,ecryptfs_sig=$SIG1,ecryptfs_fnek_sig=$SIG2,passwd=$(echo $PASS) .Private $TARGET

ls $TARGET

> Another interesting thing about mount.ecryptfs is that it effectively ignores the ecryptfs_sig option.
This still holds with ecryptfs-utils 103-5 rendering eCryptFS completely non-customizable.

I am having the same problem, and then suddenly after a gazillian tries, it works. It's not about the keys or encrpytion. The problem is that the "mount" command is trying to mount to an existing directory, but it fails saying "no such file or directory".

mount(2) system call failed: No such file or directory.

Btw, my ecryptfs_sig= is always forced to something I don't give.
example
I add the option -o ecryptfs_sig=blablablalba it always outputs ecryptfs_sig=27471f2ec87cf83f in my case. The fnek sig "listens" to my input or options.

Same with:
/sbin/mount.ecryptfs_private extramount: No such file or directory

This has been working for 3 years btw, I updated to 17.10 and this started happening.
All of a sudden after many tries, it mounts correctly.

Only this makes it work:
start

ecryptfs-manager; exit;
mount.ecryptfs_private extramount

https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1726873