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

Bug #455709 reported by Martin Albisetti on 2009-10-19
This bug affects 17 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
Dustin Kirkland 

Bug Description

Binary package hint: ecryptfs-utils

"sudo mount -t ecryptfs .Private /mnt/private" doesn't extract fnek signature properly, and disables filename encryption by default.
When a user or a private folder is created, or a user migrates their home, there is filename encryption by default, the key is different and it can be extracted from the passphrase.
Users therefore don't manage to access backup copies of their home, or only achieve it after quite a lot of hacking.

Expected behavior: "sudo mount -t ecryptfs .Private /mnt/private" extracts both keys from the passphrase, adds them to the keyring, and enables filename encryption afther the user types the passphrase and hits the enter key 5 times.

When trying to mount my encrypted home from an external disc, doing the following command:
mount -t ecryptfs -o ecryptfs_sig=<FIRST_SIG>,ecryptfs_fnek_sig=<SECOND_SIG>,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 SRC_DIR TARGET_DIR

I get "mounting eCryptfs: [-2] No such file or directory"

The current workaround is:

- sudo su -
- keyctl clear @u
- keyctl list @u
(should be empty)
- ecryptfs-insert-wrapped-passphrase-into-keyring /path/to/your/wrapped-passphrase
- keyctl list @u
- mount.ecryptfs /path/to/your/encrypted/data /mnt/your/mount/dir
(it will first prompt you for a passphrase)

Open another terminal and run:
- ecryptfs-unwrap-passphrase /path/to/your/wrapped-passphrase
- copy and paste that long/random passphrase back into your other terminal, where you're doing the mount, this is your mount passphrase
- select (aes, 16, no passthrough)
- select yes for filename encryption
- in your other terminal, tail -n1 /path/to/your/Private.sig
- this is your fnek sig
- copy and paste this into your mount window
- Enter

You should have it mounted, but maybe not something you should use reliably.

ProblemType: Bug
Architecture: i386
Date: Mon Oct 19 16:03:06 2009
DistroRelease: Ubuntu 9.10
Package: ecryptfs-utils 81-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: ecryptfs-utils
Uname: Linux 2.6.31-14-generic i686

Martin Albisetti (beuno) wrote :
Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Dustin Kirkland (kirkland)
Martin Albisetti (beuno) wrote :

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

Dustin Kirkland  (kirkland) wrote :


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.


Martin Albisetti (beuno) wrote :

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
Enable plaintext passthrough (y/n) [n]: n
Attempting to mount with the following options:
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


Alex Beels (arbeels-ossf) wrote :

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:

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?

Alex Beels (arbeels-ossf) wrote :

After much searching around, I found your article in Linux Magazine:

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?

Alex Beels (arbeels-ossf) wrote :
Download full text (3.3 KiB)


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


Alex Beels (arbeels-ossf) wrote :

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

Leo (leorolla) wrote :

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


Leo (leorolla) on 2010-08-17
summary: - "mounting eCryptfs: [-2] No such file or directory" when trying to mount
- encrypted home
+ "mounting eCryptfs: [-2] No such file or directory" mount.ecryptfs
+ default behavior is inconsistent with ecryptfs-mount-private, ecryptfs-
+ migrate-home, etc.
Leo (leorolla) on 2010-08-17
description: updated
Changed in ecryptfs-utils (Ubuntu):
status: Confirmed → Triaged
Jaroslav Malec (dzardacz) wrote :

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

forevertheuni (forevertheuni) wrote :

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

forevertheuni (forevertheuni) wrote :

Only this makes it work:

ecryptfs-manager; exit;
mount.ecryptfs_private extramount


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions