Error mounting ecryptfs 2 no such file or directory

Ecryptfs does not provide a helpful error when it fails to find a passphrase in the user’s kernel keyring when mounting an encrypted directory.

The solution is to show an error that says, «Failed to perform eCryptfs mount, stored passphrase not found: [-32]»

The error reported by ecryptfs is the following, in system log:

mount.ecryptfs: Failed to perform eCryptfs mount: [-32]

in console output:

mount: mount(2) failed: No such file or directory
Error mounting eCryptfs: [-1] Operation not permitted

Below is the console output:

eric@skylab:~$ sudo ./mount.sh 
Unable to find a list of options to parse, defaulting to interactive mount
Passphrase: 
Select cipher: 
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32
 2) blowfish: blocksize = 8; min keysize = 16; max keysize = 56
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32
 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32
 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16
Selection [aes]: 
Select key bytes: 
 1) 16
 2) 32
 3) 24
Selection [16]: 
Enable plaintext passthrough (y/n) [n]: 
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [d395309aaad4de06]: be877764c5918621
Unable to find a list of options to parse, defaulting to interactive mount
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=be877764c5918621
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=d395309aaad4de06
mount: mount(2) failed: No such file or directory
Error mounting eCryptfs: [-1] Operation not permitted
Check your system logs; visit <http://ecryptfs.org/support.html>

Ecryptfs — mount: mount(2) failed: No such file or directory

Ecryptfs does not provide a helpful error when it fails to find a passphrase in the user’s kernel keyring when mounting an encrypted directory.

The solution is to show an error that says, «Failed to perform eCryptfs mount, stored passphrase not found: [-32]»

The error reported by ecryptfs is the following, in system log:

in console output:

Below is the console output:

2 Answers 2

Run the ecryptfs add passphrase command with the filename encryption key (if you’re encrypting the filenames)

It’s a common mistake when you are going to mount the old home directory but actually unsuccessfully mounting your current user’s encrypted home (if old and new usernames are the same).

/home/ /.Private is a symlink to /home/.ecryptfs/ /.Private . On a new system it points to your current home directory, not the old home directory you probably trying to mount.

So be aware to mount .ecryptfs/ /.Private , not just /.Private .

Hot Network Questions

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.14.43159

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

ecryptfs-mount-private failure in Ubuntu 18.04: mount: No such file or directory

ecryptfs is not installed by default in Ubuntu 18.04 (as already mentioned in this AU question).

When I installed ecryptfs via apt-get everything seemed to work fine at first. But after a reboot I get the following error when using ecryptfs-mount-private :

mount: No such file or directory

Any idea how to fix this problem?
It seems to be solved in Linux Mint 19 Tara.

3 Answers 3

Update 2019 Sept:

This bug is now appearing for me in Debian 10 (buster). After some additional investigation, the problem seems to be a missing entry in /etc/pam.d/lightdm

I believe there should be a line:

Original, 2018 Sept post, the following work-around still works, but the fix above might be more correct:

With Ubunutu 18.04 and lightdm / systemd (the GUI login screen) there is something broken wrt Kernel keyring (as of 2018 Sept). This breaks some functionality in the ecryptfs scripts, which make use of the session key-ring.

After logging into your account via the GUI (lightdm), you will notice that your session keyring is not initialized correctly:

There are several work-arounds to this. One was noted by @serg-tt which uses a Linux Console login.

To fix this bug, and get the default user session keyring applied after a GUI login, I put a (temporary) fix by adding a file:

The contents of this file:

After applying this fix, you would need to log out and log back in again.

Источник

problem with ecryptfs-recover-private: mount(2) failed

I’m in the process of moving my OS and data from one drive to another within the same computer. (I got a nice, new SSD.) My old home directory had an encrypted sub directory inside, and I’d like to access the encrypted directory from my new install. I’m trying to use ecryptfs-recover-private . However, I run into the following error.

I run into the same problem if I let ecryptfs-recover-private find the directory on its own or if I say no to the login passphrase but use the mount passphrase instead.

(I realize there are several, similar questions on this site, but none seem to quite cover my situation.)

6 Answers 6

So this simple command ecryptfs-recover-private , proved to be unreliable. None of the metohd above worked for me, trying to move from ecryptfs to LUKS container.

What did work, was the manual method describe in ubuntu community wiki

• select 3 (use a passphrase key type, and use your recovered passphrase aka unwrapped-passphrase)
• select aes (use the aes cipher)
• select 16 (use a 16 byte key)
• enable plaintext passthrough: n
• enable filename encryption: y

I’m not sure why this happens — maybe a screw-up in the kernel keyring when using the same LOGIN passphrase on your new setup as on the one you try to recover.

That said, adding the wrapped passphrase into the kernel keyring before trying to recover the filesystem works (be sure to use sudo on both commands below):

I’m currently using debian testing and I recently needed to recover a file from the backup of my encrypted .Private folder. The backup is stored on my NAS. I experienced the same issue as you. Manually inserting the wrapped passphrase did not help and manually mounting the cifs filesystem (from my NAS) by root instead of creating the mount as my main user (to prevent right conflicts and whatever) did also not help.

However, after plainly rebooting my system, I could directly use the ecryptfs-recover-private command to mount the .Private folder, which itself was located on the cifs filesystem.

Though this is not explaining what’s going wrong and it’s one of the more frustrating hints you could get as a linux user:

reboot your system and try again 🙂

I had similar errors after I renamed the previous (original) POSIX username to old_user (and ) and then created a new user with the original (previous username’s) name.

To be able to mount the encrypted home directory from the old_user, I had to remake the symbolik links for .encryptfs and .Private in its folder (as they had poinded to /home/original_name/).

After that, the following command mounted the old home without any problem. /usr/bin/ecryptfs-recover-private /home/old_user/.Private

I spent hours on this problem not understanding why these simple commands did not work. I found, there are misleading links in . /home/.ecryptfs and . /home/.ecryptfs /username/.ecryptfs.

EDIT: the following solution needs to be confirmed. The relink may not be mandatory, but the parameters given to ecryptfs-recover-private may be of source of the issue.

My solution was to relink with relative path the file .Private and .ecryptfs in /home/.ecryptfs/

In my case the home user I wanted to read was in /mnt/sda5/home and user was guy

If you list the files in the home directory, your have the following links (berefore my correction)

so the files are linking to the current /home and user and not the ones you are trying to read, confusing you and the mounting commands.

After correction I implemented:

My solution was to relink with relative path the file .Private and .ecryptfs

After you can mount manually the home directory manually or using

(you will need your MOUNT passphrase — a serie of 32 characters-)

Источник

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

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= SIG>,ecryptfs_ fnek_sig= 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
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcVersionSign ature: Ubuntu 2.6.31- 14.48-generic
SourcePackage: ecryptfs-utils
Uname: Linux 2.6.31-14-generic i686

• Dependencies.txtEdit (1.5 KiB, text/plain; charset=»utf-8″)
• XsessionErrors.txtEdit (548.7 KiB, text/plain; charset=»utf-8″)

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

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= , ecryptfs_ sig= ,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.

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-9a992cd31c e8/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= a521ad46fa60c9c 7
ecryptfs_ key_bytes= 16
ecryptfs_ cipher= aes
ecryptfs_ sig=a521ad46fa6 0c9c7
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 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.

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= a521ad46fa60c9c 7
ecryptfs_ key_bytes= 16
ecryptfs_ cipher= aes
ecryptfs_ sig=a521ad46fa6 0c9c7
«»»

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?

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.

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.

Источник

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
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: ecryptfs-utils
Uname: Linux 2.6.31-14-generic i686

Comments

In short, user’s file wrapped-passphrase had wrong permissions(should be -rw------- user user, were -rw------- root root).

Ran ecryptfs-mount-private command(entered login password) using strace like:

strace -o /tmp/strace.log -e trace=file ecryptfs-mount-private

Contents of /tmp/strace.log:

user@host:~$ sudo strace -o /tmp/strace.log -e trace=file ecryptfs-mount-private
[sudo] password for user:
Enter your login passphrase:
Inserted auth tok with sig [3ab5cd8e5f8c5acb] into the user session keyring
fopen: No such file or directory
user@host:~$ cat /tmp/strace.log
execve("/usr/bin/ecryptfs-mount-private", ["ecryptfs-mount-private"], [/* 13 vars */]) = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
getcwd("/home/user", 4096)                = 9
open("/usr/bin/ecryptfs-mount-private", O_RDONLY) = 3
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3872, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
stat("/home/user/.ecryptfs/wrapping-independent", 0x7fff65e61c30) = -1 ENOENT (No such file or directory)
open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3873, si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
stat("/home/user/.ecryptfs/wrapped-passphrase", {st_mode=S_IFREG|0600, st_size=58, ...}) = 0
stat("/home/user/.ecryptfs/Private.sig", {st_mode=S_IFREG|0600, st_size=34, ...}) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3874, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
stat("/usr/local/sbin/stty", 0x7fff65e61c40) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/stty", 0x7fff65e61c40) = -1 ENOENT (No such file or directory)
stat("/usr/sbin/stty", 0x7fff65e61c40)  = -1 ENOENT (No such file or directory)
stat("/usr/bin/stty", 0x7fff65e61c40)   = -1 ENOENT (No such file or directory)
stat("/sbin/stty", 0x7fff65e61c40)      = -1 ENOENT (No such file or directory)
stat("/bin/stty", {st_mode=S_IFREG|0755, st_size=72496, ...}) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3875, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3876, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3877, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3878, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3879, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3880, si_uid=0, si_status=0, si_utime=68, si_stime=0} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3881, si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
+++ exited with 1 +++

So, we see that there’s not enough information. Ran the same command(entered login password), but with flag -f to trace child processes and using root’s rights:

sudo strace -o /tmp/strace2.log -f -e trace=file ecryptfs-mount-private`

Part of contents of /tmp/strace2.log file:

...
3963  open("/root/.ecryptfsrc", O_RDONLY) = -1 ENOENT (No such file or directory)
3963  open("/home/user/.ecryptfs/wrapped-passphrase", O_RDONLY) = 3
...
3964  open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
3964  open("/root/.ecryptfs/Private.mnt", O_RDONLY) = -1 ENOENT (No such file or directory)
3964  open("/dev/shm/ecryptfs-root-Private", O_RDWR|O_CREAT|O_NOFOLLOW, 0600) = 3
3964  open("/root/.ecryptfs/Private.sig", O_RDONLY) = -1 ENOENT (No such file or directory)
3964  +++ exited with 1 +++
3954  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3964, si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
3954  +++ exited with 1 +++

As we can see, it can’t find a file Private.sig of root; it looks like it should be ran by user who encrypted directory we are trying to recover instead of running in a particular directory.

All in all, I ran this command(entered login password) with user’s rights:

strace -o /tmp/strace3.log -f -e trace=file ecryptfs-mount-private`

Part of contents of /tmp/strace3.log file:

...
4137  open("/lib/x86_64-linux-gnu/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
4137  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4137  open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
4137  open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
4137  open("/home/user/.ecryptfsrc", O_RDONLY) = -1 ENOENT (No such file or directory)
4137  open("/home/user/.ecryptfs/wrapped-passphrase", O_RDONLY) = -1 EACCES (Permission denied)
4137  open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
4137  +++ exited with 1 +++
4112  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4137, si_uid=1000, si_status=1, si_utime=0, si_stime=0} ---
...

As we can see now, an ecryptfs-mount-private utility can’t access user’s wrapped-passphrase file which resulted in Permission denied message.

Checked /home/user/.ecryptfs/wrapped-passphrase file’s permissions and they were:

-rw------- 1 root root

Changed owner of this file via sudo chown user:user /home/user/.ecryptfs/wrapped-passphrase to user and reran above (ecryptfs-mount-private) command without strace(entered login password) which resulted in success message:

INFO: Your private directory has been mounted.
INFO: To see this change in your current shell:
  cd: /home/user

victorponomarev, нет у меня на чем потренироваться, попробовать. Но некоторые вещи я не понимаю как и что ты делаешь. Самая первая команда, например, что делает или должна делать? Ведь сразу на нее ответ системы, переведенный через Гугл гласит:
«Невозможно найти список опций для разбора, недобросовестный на интерактивную монтировки»

Так чего ж там продолжать?

Я бы сделал так:
— загрузился с LiveCD/USB
— проверил, есть ли в системе этот самый ecryptfs, например я в своей системе набираю в терминале, а мне система смотри что отвечает:

lynx@lynx:~$ ecryptfs
Команда 'ecryptfs' не найдена, возможно вы имели в виду:
 Команда 'ecryptfsd' из пакета 'ecryptfs-utils' (main)
ecryptfs: команда не найдена
lynx@lynx:~$ ecryptfsd
Программа 'ecryptfsd' на данный момент не установлена.  Вы можете установить её, выполнив:
sudo apt-get install ecryptfs-utils— проверил что там и куда уже смонтировалось:

lynx@lynx:~$ mount— только после этого сделал бы что рекомендуют в документации:

lynx@lynx:~$ sudo -i— потом просто, без выкрутасов смонтировал бы нужный мне раздел в /mnt:

root@lynx:~# mount /dev/sdXY /mnt— и только потом стал бы эти екриптовские команды вводить, и, даже не знаю, может быть сначала в /mnt нужно перейти

Как-то вот так. Ну а на практике потренироваться пока не на чем.

Пользователь добавил сообщение 30 Декабря 2016, 22:00:55:

Само. Но что от этого меняется?

Подумал над этим вопросом. Так вот в разных Ubuntu по-разному это монтирование происходит.
В 10.04, а может быть и других при шлепке в ФМ монтируется в /media. А в более молодых Ubuntu приходилось встречать, что монтируется в /media/<user> или в /media/root.

То есть зависит от системы. Вероятно поэтому и советуют самому монтировать через терминал в специальную директорию /mnt.

Ubuntu 8.10 (Intrepid Ibex) brought an interesting new security feature to both desktop and server users: the Encrypted ~/Private Directory.

Setup Your Encrypted Private Directory

1. Install ecryptfs-utils

    sudo apt-get install ecryptfs-utils 

2. Setup your private directory

    ecryptfs-setup-private 

   Warning: Do not use  ecryptfs-setup-private —noautomount  if your login manager is kdm. See bug #643970.

3. Enter your login password, and either choose a mount pass phrase or generate one.

   • Record both pass phrases in a safe location!!! They will be required if you ever have to recover your data manually.

4. Logout, and Log back in to establish the mount

Use Your Encrypted Private Directory

After logging back in, all content of any files or folders you write in ~/Private will be encrypted when written to the disk, in the hidden directory ~/.Private.

Storing Your Keys, Email and other Data in ~/Private

It can be a good idea to move the content of your .evolution/, .ssh/ and .gnupg/ in ~/Private and replacing them with a symlink.

1. Make sure that the application whose data you want to protect (e.g. Firefox or Evolution) is not running

    ps -ef | grep evolution 
2. Move the application’s data directory (e.g. ~/.mozilla or ~/.evolution) into your ~/Private directory

    mv ~/.evolution ~/Private 

3. Establish a symbolic link from the old location to new location

    ln -s ~/Private/.evolution ~/.evolution 

Using in conjunction with Auto-login

Automatic, password-less desktop logins will yield an un-mounted ~/Private directory. This is quite deliberately by design, ensuring that you must enter a password to access the encrypted data in the ~/Private directory.

If you use the ecryptfs-setup-private from ecryptfs-utils version 53-1ubuntu13 or beyond, if you open your ~/Private folder in Nautilus or Konqueror, you should see two files, README.txt, and «Access Your Private Data». If you click on «Access…», you will be prompted for your login password and your private data will be accessible.

If you created your ~/Private directory with an older version of ecryptfs-utils, you will need to manually establish a symlink for the «Access Your Private Data» icon. Here’s how:

1. Update to the latest ecryptfs-utils package

   •  $ sudo apt-get update && sudo apt-get upgrade 

2. Ensure that ~/Private is not mounted

   •  $ ecryptfs-umount-private 

3. Establish the links in your unmounted ~/Private

   •  cd ~/Private && sudo ln -sf /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt README.txt && sudo ln -sf /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop Access-Your-Private-Data.desktop 

Recovering Your Data Automatically

Use ecryptfs-recover-private

1. boot the target system using an Ubuntu 11.04 Desktop LiveCD
2. make sure that your target system’s hard drive is mounted
3. open a terminal
4. run ‘sudo ecryptfs-recover-private’
5. follow the prompts
6. access your decrypted data and save somewhere else

Recovering Your Data Manually

These steps should only be required in unusual, or emergency circumstances, when you must manually mount your encrypted ~/Private directory to recover your data. You can use this to mount your data if it’s backed up on a different system, or using a LiveCD, as long as it is running at least the Linux 2.6.26 kernel.

1. If you use encrypted filenames (standard in Ubuntu >= 9.04) you have to do the following first:

   •  sudo ecryptfs-add-passphrase —fnek 

   •  Passphrase:  (Enter the mount passphrase you recorded when you setup the mount—this passphrase is different from your login passphrase.)

   • You should now get two lines looking like this:

   •  Inserted auth tok with sig [9986ad986f986af7] into the user session keyring 

   •  Inserted auth tok with sig [76a9f69af69a86fa] into the user session keyring  (write down the second value in the square brackets)

2. Mount using sudo:

   •  sudo mkdir -p /home/username/Private  

   •  sudo mount -t ecryptfs /home/username/.Private /home/username/Private 

   •  Selection: 3  (use a passphrase key type)

   •  Passphrase:  (Enter the mount passphrase you recorded when you setup the mount—this passphrase is different from your login passphrase.)

   •  Selection: aes  (use the aes cipher)

   •  Selection: 16  (use a 16 byte key)

   •  Enable plaintext passthrough: n 

   •  Enable filename encryption: y  (This and the following options only apply if you are using filename encryption)

   •  Filename Encryption Key (FNEK) Signature:  (the value you wrote down from the second line above)

Note: This is a common error that you get if you use a invalid directory when you give the mount command.

Error mounting eCryptfs: [-2] No such file or directory
Check your system logs; visit <http://launchpad.net/ecryptfs>

The system logs are located in /var/log. You most likely want to take a look at these 3 log files.

1. /var/log/syslog
2. /var/log/user.log
3. /var/log/auth.log

Take a look at this link if you want more information about system logs. http://www.cyberciti.biz/faq/ubuntu-linux-gnome-system-log-viewer/

Assuming you entered your passphrase correctly, you should be able to temporarily access your data at  /home/username/Private . Since you are using superuser privileges instead of your regular user account, you may get a warning that you might have entered the passphrase wrong, even if you didn’t:

WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

It is safe to ignore this warning.

Live CD method of opening a encrypted home directory

There are two methods of using the LiveCd to open a encrypted home directory. The first will be the long way. The long way gives you more functionality in your home directory. It is also easier to do. The second will be the short way. The second way requires you to know about your system and how you partitioned it. It is more difficult to get more functionality, but is still possible. I prefer the long way.

Long way

The first thing you need to do is mount your linux partitions. Please use nautilus to do this. The guide will make a lot more sense if you do this. Nautilus is the default file manager of gnome. If you are using a kde or xfce live cd the syntax may be different below so please install nautilus if that is the case with this command.

~ $ sudo apt-get install nautilus

If you are confident in your ability to use the mount the command then you can use that, but you will have to manipulate the directory information below for it to work properly. Use this command to to find your Linux partitions.

~ $ sudo fdisk -l

Note: If you are trying to recover some data by doing this it is a good idea to mount your partition in read only mode. To do this use the command below.

sudo mount -o remount,ro /dev/sda6

My output

~ $ sudo fdisk -l

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c8b89

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        1245     9999360   83  Linux
/dev/sda2            1246        5478    33998849    5  Extended
/dev/sda3   *        5479       12161    53681197+   7  HPFS/NTFS
/dev/sda5            1246        1743     3998720   82  Linux swap / Solaris
/dev/sda6            1744        5478    29999104   83  Linux

In this case you would have to to mount /dev/sda1 and /dev/sda6. I am going to assume you know how to do this if you want to manually mount your partitions.

Next you need find your «.Private» directory. It is possible to have a «.Private» symlink. So be careful. Use this command to find it.

~ $ sudo find / -type d -iname '.Private' 2>/dev/null

You should get something similar to this:

~ $ /media/<disk>/.ecryptfs/<user>/.Private
~ $ /media/<disk>/<user>/.Private

In my case I got the first one.

~ $ sudo find / -type d -iname '.Private' 2>/dev/null
/media/4fa4e92e-3532-48fd-a83d-6ea340a669b6/.ecryptfs/bob/.Private

Next you need to find your keyring keys. This requires that you have your mount passphrase. You recorded when you setup the mount—this passphrase is different from your login passphrase. If you don’t have your mount passphrase please read here (Recovering Your Mount Passphrase). Lets move on to getting those keyring keys. Put the sudo command into the terminal that you see below. This will be a interactive prompt. The left side of what you see is what you will see and the right side will give you more information. The second keyring in the square brackets is the important part.

•  sudo ecryptfs-add-passphrase —fnek 

•  Passphrase:  (Enter the mount passphrase you recorded when you setup the mount—this passphrase is different from your login passphrase.)

• You should now get two lines looking like this:

•  Inserted auth tok with sig [9986ad986f986af7] into the user session keyring 

•  Inserted auth tok with sig [76a9f69af69a86fa] into the user session keyring  (write down the second value in the square brackets)

Next you need to mount the appropriate «.Private» directory. That you found earlier. You also need to understand the mount syntax to mount everything correctly.

sudo mount -t ecryptfs sdtm ldm

• sudo, mount, -t, ecryptfs, Just copy and paste those. They stay the same.
• sdtm = source directory to mount
• ldm = location directory to mount at

I recommend mounting at /home/username. Replace username with whatever username you want to use. I will be mounting at /home/bob. Since this is a live cd the directory will not exist, so you need to create it. Use this command to create your directory.

sudo mkdir /home/username

After you have created the directory that you want to mount at, please use this command that I showed you above.

sudo mount -t ecryptfs sdtm ldm

An example of putting all of this together would be:

sudo mount -t ecryptfs /media/4fa4e92e-3532-48fd-a83d-6ea340a669b6/.ecryptfs/bob/.Private /home/bob

Next you will have a interactive prompt.

•  Passphrase:  (Enter the mount passphrase you recorded when you setup the mount—this passphrase is different from your login passphrase.)

•  Selection: aes  (use the aes cipher)

•  Selection: 16  (use a 16 byte key)

•  Enable plaintext passthrough: n 

•  Enable filename encryption: y  (This and the following options only apply if you are using filename encryption)

•  Filename Encryption Key (FNEK) Signature:  (The second keyring in the square brackets from above that I said would be important.)

If everything worked out correctly you should be able to see everything in /home/username. My files will be in /home/bob.

There are several possible things that can go wrong. I will cover them here.

Error mounting eCryptfs: [-2] No such file or directory
Check your system logs; visit <http://launchpad.net/ecryptfs>

This is a common error that you get if you use a invalid directory when you give the mount command.

It is possible to get the message Mounted eCryptfs and still not be able to see your data. This most likely means that you did not mount «.Private» directory. It is also possible that you mounted the wrong directory. This happened to me and was quite difficult to figure out. Thanks to this question on launchpad I was able to figure it out.

https://answers.launchpad.net/ecryptfs/+question/114209

Please check eCryptfs for any other problems.

http://ecryptfs.sourceforge.net/ecryptfs-faq.html

Short advanced way

As I said this method is more difficult. If your home directory is installed on your / root partition it makes life easier. If you have a /home partition then you need to find both your /home partition and / root partition. Use nautilus to mount your linux partitions. Then use these two commands so you can figure out if you have a /home partition or not.

~ $ sudo fdisk -l
~ $ df -h

Note: The linux partitions must be mounted or you will not be able to get the information you need.

Here is my output.

~ $ sudo fdisk -l

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c8b89

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        1245     9999360   83  Linux
/dev/sda2            1246        5478    33998849    5  Extended
/dev/sda3   *        5479       12161    53681197+   7  HPFS/NTFS
/dev/sda5            1246        1743     3998720   82  Linux swap / Solaris
/dev/sda6            1744        5478    29999104   83  Linux

~ $ df -h
Filesystem            Size  Used Avail Use% Mounted on
aufs                  1.6G  1.5G  103M  94% /
none                  1.6G  280K  1.6G   1% /dev
/dev/sr0              700M  700M     0 100% /cdrom
/dev/loop0            682M  682M     0 100% /rofs
none                  1.6G  5.3M  1.6G   1% /dev/shm
tmpfs                 1.6G   34M  1.6G   3% /tmp
none                  1.6G   92K  1.6G   1% /var/run
none                  1.6G     0  1.6G   0% /var/lock
/dev/sda3              52G   32G   21G  61% /media/D07C698F7C697160
/dev/sda6              29G  9.4G   18G  35% /media/4fa4e92e-3532-48fd-a83d-6ea340a669b6
/dev/sda1             9.4G  4.2G  4.9G  47% /media/4fb33fae-d738-405d-8ba1-bc1ede832411

In my case I have a /home partition and / root partition. I can tell this by looking at /dev/sda1 and /dev/sda6. If you look at the sudo fdisk -l you can see /dev/sda1 and /dev/sda6 are my linux partitions. If you look at the df -h I can see /dev/sda6 is much bigger than /dev/sda1 so I know /dev/sda6 is my /home partition.

You need to unmount the partitions that you just mounted. Change the partition numbers to whatever the partition numbers are.

~ $ umount /dev/sda1
~ $ umount /dev/sda6

If you have a home directory and / root partition do this. http://blog.dustinkirkland.com/2009/03/mounting-your-encrypted-home-from.html

ubuntu@ubuntu$ sudo mount /dev/sda1 /mnt
ubuntu@ubuntu$ sudo mount -o bind /dev /mnt/dev
ubuntu@ubuntu$ sudo mount -o bind /dev/shm /mnt/dev/shm
ubuntu@ubuntu$ sudo mount -o bind /proc /mnt/proc
ubuntu@ubuntu$ sudo mount -o bind /sys /mnt/sys
ubuntu@ubuntu$ sudo chroot /mnt
root@ubuntu$ su - kirkland
kirkland@ubuntu$ ecryptfs-mount-private
Enter your login passphrase:
Warning: Using default salt value (undefined in ~/.ecryptfsrc)
Inserted auth tok with sig [xxx] into the user session keyring
kirkland@ubuntu$ cd $HOME
kirkland@ubuntu$ ls -alF
...
kirkland@ubuntu$ cat .profile

Here is an example of putting this into action. I attached the thread decribes what is going on. http://ubuntuforums.org/showthread.php?t=1643532

# Set up chroot :
# Note my install (both home and /) on sda3

ubuntu@ubuntu:~$ sudo mount /dev/sda3 /mnt
ubuntu@ubuntu:~$ sudo mount -o bind /dev /mnt/dev
ubuntu@ubuntu:~$ sudo mount -o bind /dev/shm/ /mnt/dev/shm
ubuntu@ubuntu:~$ sudo mount -o bind /proc /mnt/proc
ubuntu@ubuntu:~$ sudo mount -o bind /sys /mnt/sys

# As you say, there is no "bodhi" on the live CD:
ubuntu@ubuntu:~$ id bodhi
id: bodhi: No such user

# But after we chroot ...
ubuntu@ubuntu:~$ sudo chroot /mnt
root@ubuntu:/# id bodhi
uid=1000(bodhi) gid=1000(bodhi) groups=1000(bodhi),4(adm),20(dialout),24(cdrom),46 (plugdev),111(lpadmin),119(admin),122(sambashare)


# su to bodhi
root@ubuntu:/# su - bodhi
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

# But home is encrypted ...

bodhi@ubuntu:~$ ls
Access-Your-Private-Data.desktop README.txt

# Decrypt home
bodhi@ubuntu:~$ ecryptfs-mount-private
Enter your login passphrase:
Inserted auth tok with sig [b0d08471978769db] into the user session keyring

INFO: Your private directory has been mounted.
INFO: To see this change in your current shell:
cd /home/bodhi

# We will not see the data until we cd into the decrypted home
# read the README.txt =)
bodhi@ubuntu:~$ ls
Access-Your-Private-Data.desktop README.txt

# so cd ...
bodhi@ubuntu:~$ cd

# Now we can see the decrypted data ...
bodhi@ubuntu:~$ ls
bin Desktop Downloads Music Public Videos
bzr Documents examples.desktop Pictures Templates zen 

We can access the data, as root, from the live CD (gksu nautilus) at /mnt/home/bodhi

If you have a /home partition and / root partition do this. I will now assume you know where /home partition and / root partition. Mount your /root partition like this. Replace the appropriate number for where your /root partition is.

sudo mount /dev/sda1 /mnt

Mount your /home partition like this. Replace the appropriate number for where your /home partition is.

sudo mount /dev/sda6 /mnt/home

After that setup you chroot.

sudo mount -o bind /dev /mnt/dev
sudo mount -o bind /dev/shm/ /mnt/dev/shm
sudo mount -o bind /proc /mnt/proc
sudo mount -o bind /sys /mnt/sys

Then chroot

sudo chroot /mnt /bin/bash

su to your username. My username is bob so I will use bob.

su - bob

Then decrypt home.

ecryptfs-mount-private

An example of this.

mint@mint ~ $ ls /media/4fa4e92e-3532-48fd-a83d-6ea340a669b6
bob  joe  lost+found  Recycled  RECYCLER
mint@mint ~ $ ls /media/4fb33fae-d738-405d-8ba1-bc1ede832411
bin   home        media       opt       root     sys  vmlinuz
boot  initrd.img  mnt         proc      sbin     tmp
dev   lib         OldHome     Recycled  selinux  usr
etc   lost+found  OldPrivate  RECYCLER  srv      var
mint@mint ~ $ umount /media/4fa4e92e-3532-48fd-a83d-6ea340a669b6
mint@mint ~ $ umount /media/4fb33fae-d738-405d-8ba1-bc1ede832411
mint@mint ~ $ sudo mount /dev/sda1 /mnt
mint@mint ~ $ sudo mount /dev/sda6 /mnt/home
mint@mint ~ $ sudo mount -o bind /dev /mnt/dev
mint@mint ~ $ sudo mount -o bind /dev/shm/ /mnt/dev/shm
mint@mint ~ $ sudo mount -o bind /proc /mnt/proc
mint@mint ~ $ sudo mount -o bind /sys /mnt/sys
mint@mint ~ $ sudo chroot /mnt /bin/bash
 _______________________________________
( Many changes of mind and mood; do not )
( hesitate too long.                    )
 ---------------------------------------
  o
   o
       ___  
     {~._.~}
      ( Y )
     ()~*~()   
     (_)-(_)   
mint / # su - u bob
Unknown id: u
mint / # su - bob
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
 _________________________________________
( "I don't think you have to go through   )
( the process of reconfiguring X as I did )
( - that was partly because the           )
( frustration made me brain dead."        )
(                                         )
( Husse Apr 5 2007                        )
 -----------------------------------------
  o
   o
       ___  
     {~._.~}
      ( Y )
     ()~*~()   
     (_)-(_)   
bob@mint ~ $ ecryptfs-mount-private
Enter your login passphrase:
Inserted auth tok with sig [3bacfa4dde6b90dd] into the user session keyring

INFO: Your private directory has been mounted.
INFO: To see this change in your current shell:
  cd /home/bob

bob@mint ~ $ ls -alF
total 32
drwx------ 5 bob  bob  4096 2010-09-03 16:18 ./
drwxr-xr-x 8 root root 4096 2010-08-21 18:16 ../
lrwxrwxrwx 1 bob  bob    56 2010-05-24 01:55 Access-Your-Private-Data.desktop -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop
-rw------- 1 bob  bob   214 2010-09-03 16:18 .bash_history
drwx------ 3 bob  bob  4096 2010-07-15 23:29 .cache/
lrwxrwxrwx 1 bob  bob    29 2010-05-24 01:55 .ecryptfs -> /home/.ecryptfs/bob/.ecryptfs/
-rw------- 1 bob  bob    16 2010-09-03 16:18 .esd_auth
drwx------ 2 bob  bob  4096 2010-11-12 15:00 .gconfd/
lrwxrwxrwx 1 bob  bob    28 2010-05-24 01:55 .Private -> /home/.ecryptfs/bob/.Private/
drwx------ 2 bob  bob  4096 2010-11-29 21:18 .pulse/
-rw------- 1 bob  bob   256 2010-09-03 16:18 .pulse-cookie
lrwxrwxrwx 1 bob  bob    52 2010-05-24 01:55 README.txt -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt
bob@mint ~ $ pwd
/home/bob
bob@mint ~ $ cd /home/bob
bob@mint ~ $ ls -alF
total 16672
drwx------ 92 bob  bob    28672 2010-12-09 01:12 ./
drwxr-xr-x  8 root root    4096 2010-08-21 18:16 ../
-rw-r--r--  1 bob  bob    88038 2010-08-31 02:43 20 group list.txt
-rwxr-xr-x  1 bob  bob      191 2010-10-28 15:34 .xprofile*
bob@mint ~ $ pwd
/home/bob

To access the data, do not exit the chroot. Open a new terminal and run nautilus as root.

gksu nautilus

You can not run graphical applications directly from the chroot, you would need to connect to the chroot via a VNC or ssh -X.

Recovering Your Mount Passphrase

In the event that you did not write down your mount passphrase, you may be able to recover it by decrypting the file  /home/username/.ecryptfs/wrapped-passphrase  using your login passphrase.

•  ecryptfs-unwrap-passphrase /home/username/.ecryptfs/wrapped-passphrase

• Type your login passphrase to reveal the mount passphrase

If your login passphrase matches the passphrase used to encrypt the wrapped-passphrase file, your mount passphrase will be written to screen. Record and protect this data accordingly.

If you have lost your wrapped-passphrase file, and you did not record your mount passphrase, it is impossible to access your encrypted data.

How to Remove an Encrypted Private Directory Setup

Perhaps an Encrypted Private Directory is not for you. To remove this setup:

1. Ensure that you have moved all relevant data out of your ~/Private directory

2. Unmount your encrypted private directory

   •  $ ecryptfs-umount-private 

3. Make ~/Private writable again

   •  $ chmod 700 ~/Private 

4. Remove ~/Private, ~/.Private, ~/.ecryptfs (Note: THIS IS VERY PERMANENT AND WILL DELETE ALL YOUR FILES, NOT JUST THE ENCRYPTED COPIES!)

   •  $ rm -rf ~/Private ~/.Private ~/.ecryptfs 

5. Uninstall the utilities

   •  $ sudo apt-get remove ecryptfs-utils libecryptfs0 

Log in with the folder remaining encrypted

A possible security problem that can crop up, is the event that the user logs in and then immediately leaves the computer physically usable to another person. The Private folder is unlocked as soon as the user logs in, the owner would not have had the chance to lock the folder, and the other person can take control of the computer and access it while the owner is away.

We can stop ecryptfs from unlocking the Private folder on startup, by removing the empty file auto-mount which is located in ~/.ecryptfs/, where you also can remove the auto-umount file, if you would like ecryptsfs to stop unmounting the private folder upon shutdown and logout.

For some reason the script fails to ask for a password, when you simply log out and in. You have to reboot the machine, or you will be able to just click on the mount script and the folder is mounted.

To resolve this problem, it is possible to have the script that unmounts the Private folder to run at login, so it cannot be accessed without the password being put in first. To do this:

1. Go to System > Preferences > Startup Applications.

2. Click Add.

3. You can put anything for the Name field, something like  Lock Private Folder  for example. In the Command field, type  /usr/bin/ecryptfs-umount-private  and the Comment field can can be left blank.

4. Click Save and close the Startup Applications window. When you log in, the Private folder will be quickly unmounted before the folder can be accessed.

This is a quick and dirty solution to this problem. If there’s a better way, please replace this with it.

Caveats

• Before Ubuntu 9.04, filenames and directory names were not encrypted. This has been fixed in Ubuntu 9.04, however. (Bug #264977).

• Network mounting (NFS, CIFS, Samba) of /home will not work properly with an encrypted ~/Private (bugs #277578 & #289747).

• By design, data is not kept private to privileged users while the user is logged in. One consequence of this is if ~/Private is mounted, a backup solution may backup your decrypted files unless the backup software is configured to exclude files in ~/Private.
• If you put all of .ssh in ~/Private, you won’t be able to ssh into the system using public key authentication. In this case, you might want to only put your private key in ~/Private, and leave the rest (or at least the public keys saved in «authorized_keys» file) in the clear.
• If you choose to store application data in the ~/Private directory, those applications will not operate as expected if the ~/Private directory is unmounted.

• If you enable «automatic login» ~/Private will NOT be mounted (decrypted) automatically.

• Linux filenames are limited to 256 characters in length. When using eCryptfs encrypted filenames, filenames are padded with metadata necessary for decryption. Cleartext filenames which are already very long (> ~200 characters) will not work in eCryptfs.

Not covered in this tutorial

• How the automatic mounting of the encrypted directory works and what files need to be edited to stop the automatic mounting.

More information

If you would like more information I recommend reading these websites.

http://goshawknest.wordpress.com/2010/04/16/how-to-recover-crypted-home-directory-in-ubuntu/ http://blog.dustinkirkland.com/2009/03/mounting-your-encrypted-home-from.html#comment-form http://www.kaijanmaki.net/2009/10/26/recovering-files-from-ecryptfs-encrypted-home/ http://bodhizazen.net/Tutorials/Ecryptfs/ http://www.theirishpenguin.com/2010/09/26/accessing-your-encrypted-home-directory-in-ubuntu/

Nadeem14 wrote: ↑

Fri Aug 13, 2021 12:29 am

Recover your encrypted /home directory in just 5 steps

1.mount the home partition

2.Open terminal in the mounted partition (without elevated priveleages)

3.sudo bash

4.sudo ecryptfs-recover-private .ecryptfs/bluefox/.Private/

5.enter password and find the decrypted folder in tmp

Note: 1.Bluefox was my home directory, you replace that with your user home directory.

2.You cannot delete or rename files from the decrypted directory but can only copy them.

Thanks, this enabled me to back up some files by doing the above, then unencrypting my Veracrypt encrypted SSD drive and copying it over. Is there also a way to backup my Bookmarks in my Chrome & Vivaldi web browsers? I would like to back these up too.

I’ve also managed to get out of my login loop by executing the command

 sudo chmod u+w /home/administrator

but now the problem is it doesn’t log into my desptop environment. It loads up a GUI of a brand new install of Mint, the one where it gives a pop up «Welcome to Linux Mint» dialogue box. I don’t have any programs I’ve installed previously, such as Veracrypt, Chrome, Vivaldi, etc. Also if I go to the Home folder it’s blank as in I don’t see any of my saved documents & files I’ve been working on, as per my comments in this thread: viewtopic.php?p=2052408#p2052408

Does anyone have a solution to this and know why this is happening please?

When I open my Home directory, I see the folders Desptop, Documents, Downloads, Music, Pictures, Public, Templates & Videos. There also are two files called Access-Your-Private-Data.desktop & README.txt with both these files having a padlock icon up top right and an «x» icon at bottom left. Could this have something to do with it that needs logging into those files?

Also, when I 1st had the login loop problem I tried all different commands that others have said previous worked for them. Could that have caused the problem that now I can’t get my original desktop home folder working? I tried these commands previously:

sudo chown -Rc $USER:$USER $HOME
rm $HOME/.Xauthority $HOME/.ICEauthority

sudo chown myuser:myuser /home/myuser/.Xauthority
sudo chown -R myuser:myuser /home/myuser

chown username:username .Xauthority
sudo dpkg-reconfigure lightdm

sudo mv ~/.Xauthority ~/.Xauthority,backup
sudo service lightdm restart

Index

• What is novel about eCryptfs?
• What versions of the kernel have eCryptfs
  support?
• Will eCryptfs by itself protect all my
  data?
• Can I access the lower files while
  eCryptfs is mounted?
• What kernel options do I need to enable to
  build eCryptfs?
• On what filesystems can I expect eCryptfs
  to function?
• Why is the kernel stack such an issue with
  eCryptfs?
• What is ecryptfsd?
• What is
  ecryptfs-manager?
• Do I have to be root to mount
  eCryptfs?
• How do I store the metadata in the extended
  attribute region of the lower file?
• I am using the -o xattr
  option, but my backup tools do not preserve extended attributes. How
  can I back up the lower files?
• What about sparse files?
• How should I select my passphrase?
• How can I protect my key?
• I forgot my password/lost my key! What can I do
  to recover my data?
• How does eCryptfs compare with other Linux disk
  encryption solutions?
• Once one user can access an eCryptfs
  file, any users with permission can also access the file. Should not
  eCryptfs require all users to have the key in order to access the
  files?
• «Unable to allocate crypto cipher
with name [---]; rc = [-2]«
• «Error mounting eCryptfs; rc = [-2];
strerr = [No such file or directory]«
• «Error mounting eCryptfs; rc = [-22];
strerr = [Invalid argument]«
• «ecryptfs_parse_options: Could
not find key with description: [deadbeaf...]"
• «ecryptfs_parse_packet_set: Expected
signature of size [8]; read size [7]"
• My question isn’t answered here.

Q. What is novel about eCryptfs?

Well, nothing, to be honest. All of the techniques used in eCryptfs
are directly based on cryptographic technology that was widely known
and in practical use in the 1970’s.

Security problems often arise when software tries to «invent its own
crypto» by deviating from what has been in common practical use for a
lengthy period of time. eCryptfs sticks to tried-and-true encryption
technology.

In terms of per-file key management, eCryptfs simply uses the methods
of PGP (created by Philip Zimmermann in 1991 and formally specified as
a public standard in RFC2440 in 1998) and takes the obvious and
conceptually trivial step of applying those methods within a
filesystem service in the kernel. eCryptfs employs the well-weathered
encryption techniques that have been in common use in the community
for over two decades. Other cryptographic filesystems published and
widely used in the 1990’s use the same basic approach to encrypting
files. eCryptfs just happens to be the first such filesystem to make
it upstream in the Linux kernel.

Q. What versions of the kernel have eCryptfs support?

Linux kernel versions 2.6.19 and later have eCryptfs support. The
official mainline kernel is supported and is in active development.

Q. Will eCryptfs by itself protect all my data?

eCryptfs is just one component in a comprehensive set of mechanisms to
protect the confidentiality of your data. Simply mounting eCryptfs
over a directory in your home directory will probably not provide
sufficient coverage for everything your applications will write to
disk. For instance, applications that produce and store thumbnails of
your images may write the thumbnails to an unprotected location.

Sensitive application data will typically wind up in the following
locations, although some applications will write data to other
locations not listed here:

• Anywhere in your home directory
• The /tmp directory
• The /var directory
• The swap device

The /tmp directory and the swap device can be easily protected with
dm-crypt using a key randomly generated when the system is booted,
since the information in those locations does not need to persist
between reboots. eCryptfs must mount the /var directory prior to any
daemons or other system applications reading from or writing to that
location (including the syslog utility). eCryptfs must also mount over
the user’s home directory prior to the user logging into the system.

You will need to consider other applications that diverge from
traditional paths for storing data on a case-by-case basis. Analyzing
application behavior with the kernel auditing system is one way to
profile the behavior of an application, and explicit SE Linux rules
that only allow applications to write to encrypted mountpoints helps
prevent inadvertent information leakage. We recommend always using
eCryptfs together with appropriate Mandatory Access Control (MAC)
mechanisms to ensure that your sensitive data is always encrypted.

Proper deployment of a comprehensive per-file encryption mechanism is
a task best tackled by the entire Linux distribution. The eCryptfs
team is working closely with various major Linux distributions to help
ensure that eCryptfs is properly used as one component of a
comprehensive data protection strategy.

Q. Can I access the lower files while eCryptfs is mounted?

Accessing the lower files during an active eCryptfs mount is somewhat
like accessing a block device on which ext3 is mounted. The kernel
allows it, and it may work (depending on what you do with the data),
but it is not a good idea.

Q. What kernel options do I need to enable to build
eCryptfs?


Code maturity level options --->
  [*] Prompt for development and/or incomplete code/drivers

Newer versions of the Linux kernel now have a «Layered filesystems»
submenu under the «File systems» menu, where eCryptfs and Unionfs
reside.

Make certain that you have loaded all of the crypto modules that you
need to run eCryptfs. This includes ecb,
cbc, md5, and at least one popular symmetric
cipher, like aes.

Q. On what filesystems can I expect eCryptfs to function?

eCryptfs has been well tested on EXT3, EXT4, XFS and it should work well on
other popular local filesystems such as JFS, ReiserFS, and so
forth. Changes in the 2.6.24 kernel make eCryptfs more functional on
NFS and CIFS, although there is still a little more work to do in
order to make eCryptfs function as well on networked filesystems as it
currently works on local filesystems. This bug
tracks the issues around making eCryptfs work on top of NFS, CIFS, Samba
and WebDAV.

Q. Why is the kernel stack such an issue with eCryptfs?

eCryptfs is a stacked filesystem. This implies that eCryptfs adds on
top of whatever call stack exists with current filesystems. Each
process in the Linux kernel has a fixed maximum stack size (4k+4k or
8k). Some filesystems (such as XFS) push the limit of the stack by
themselves; adding eCryptfs on top may cause a stack overflow on these
filesystems. If you wish to use eCryptfs on XFS, I recommend that you
first perform stress tests to help determine whether your specific
configuration will lead to a kernel process stack overflow.

Q. Do I have to be root to mount eCryptfs?

eCryptfs mounts can be set up to be done by non-root users, using
the ecryptfs-setup-private utility. The root user
can also setup mount points in /etc/fstab, but the
non-root users will need to manually load their keys into the
kernel keyring.

Q. How do I store the metadata in the extended attribute region
of the lower file?

If your kernel has support for it, mount with the -o
xattr option. Be sure to preserve the extended attributes in
the lower files, or you will lose your data. Bear in mind that many
userspace utilities such as tar lack extended attribute
support, and so you need to use utilities like star with
the proper options instead.

Q. I am using the -o xattr option, but my backup
tools do not preserve extended attributes. How can I back up the lower
files?

Mount with the -o encrypted_view flag and read the files
from under the eCryptfs mount point. The files read will be encrypted,
and the cryptographic metadata will be in the headers of the encrypted
files that are passed through, even if this metadata is actually
stored in the extended attribute regions of the lower files.

Q. What about sparse files?

eCryptfs does not currently support sparse files. Sequences of
encrypted extents with all 0’s could be interpreted as sparse regions
in eCryptfs without too much implementation complexity. However, this
would open up a possible attack vector, since the fact that certain
segments of data are all 0’s could betray strategic information that
the user does not necessarily want to reveal to an attacker. For
instance, if the attacker knows that a certain database file with
patient medical data keeps information about viral infections in one
region of the file and information about diabetes in another section
of the file, then the very fact that the segment for viral infection
data is populated with data at all would reveal that the patient has a
viral infection.

Q. How should I select my passphrase?

There are plenty of good guides out there to help you choose a strong
passphrase. Here is one, for instance: http://www.iusmentis.com/security/passphrasefaq/.

Q. How can I protect my key?

Make a copy and store it in a physically secure location. For
instance, copy your public/private keypair to a USB flash drive or
write your passphrase onto a sheet of paper. Then, lock the drive and
paper in your desk drawer or put them in a safe deposit box (depending
on the sensitivity of the data that the keys protect). Future versions
of eCryptfs userspace utilities may implement key splitting functions
to provide even more paranoid levels of key protection.

Do not store your keys under the same physical security context in
which you are storing your media. It should be much harder for an
attacker to get to your keys than it is for him to get to your media.

When you use public key mode and generate a new key using
ecryptfs-manager, the generated key file is the one that
you must back up in order to access your files.

When mounting with a new key, I recommend performing a full mount,
creating a new file, unmounting, clearing the user session keyring
(keyctl clear @u), mounting again, and then trying to
access the newly created file. This minimizes the likelihood that you
will mistype a passphrase and create files that you will not be able
to later recover. When mounting in passphrase mode, make sure that the
ecryptfs_sig value matches between mounts. To help avoid the pitfall
of mistyping a passphrase on mount, eCryptfs stores a cache of
previous ecryptfs_sig values and warns the user if a mount passphrase
does not match any passphrases used for previous mounts.

Q. I forgot my password/lost my key! What can I do to recover
my data?

Nothing; you’re screwed. (Apologies
to Bruce Schneier).

If you have forgotten your passphrase, your only hope is that you
chose a weak passphrase in the first place. There is an outside chance
that you might be able to perform a successful dictionary attack to
recover your passphrase. If you manage to recover your passphrase that
way, then you may as well have not been bothering to encrypt your data
in the first place, since a malicious attacker could have done the
exact same thing to recover your passphrase.

If you selected a strong passphrase or lost your key file, you are
completely out of luck. Nobody can help you recover your data.

Q. How does eCryptfs compare with other Linux disk encryption
solutions?

eCryptfs is an actual filesystem. Some other popular disk encryption
technologies are not filesystems; they are block device encryption
layers (they provide what appears to be a physical block device to
some actual filesystem). There is no filesystem logic in these
layers. A few of the more well-known block device encryption layers
include dm-crypt, Truecrypt, and Loop-AES. Perhaps the best thing
about block device-layer encryption is that it is an order of
magnitude simpler to implement than filesystem-layer
encryption. Another advantage of block device-layer encryption is that
it will encrypt the entire filesystem, including all of the filesystem
metadata. However, for many use cases, this can turn out to be more of
a disadvantage than an advantage.

While eCryptfs uses a powerful and flexible approach to protecting
filesystem content, block device-layer encryption technology is still
required to protect swap space and certain databases that use their
own block device partition. The table below provides a
compare-and-constrast of the two technologies. I anticipate that block
device encryption will be the best solution for some people, while
stacked filesystem encryption will be the best solution for
others. Sometimes it even makes sense to use them both together, to
combine the comprehensive full-disk encryption of a block device layer
encryption technology with the transparent per-file encryption
provided by eCryptfs (this will result in double-encryption of the
file contents).

EncFS is another popular cryptographic filesystem that behaves much
like a stacked filesystem. EncFS is a userspace filesystem, and so
individual page reads and writes require additional context switches
between kernel and userspace. One advantage a userspace cryptographic
filesystem is that it is possible to use symmetric ciphers implemented
in userspace libraries, but the frequent context switching impacts
performance.

Once one user can access an eCryptfs file, any users with
permission can also access the file. Should not eCryptfs require all
users to have the key in order to access the files?

eCryptfs deliberately makes no attempt to re-implement the
discretionary and mandatory access control mechanisms already present
in the Linux kernel. eCryptfs will simply require that a File
Encryption Key (FEK) be associated with any given inode in order to
decrypt the contents of the file on disk. This prevents an attacker
from accessing the file contents outside the context of the trusted
host environment; for instance, by removing the storage device or by
booting a live CD. This is the only type of unauthorized access that
eCryptfs is intended to prevent.

Once eCryptfs has associated that FEK with the inode, it does not
impose any additional restrictions on who or what can access the
files, deferring to the standard user/group/other permissions,
capabilities, SE Linux type enforcement, and so forth to regulate
access to the files. eCryptfs maintains no pedigree regarding how the
FEK found its way to the inode, so it has no way of knowing that any
particular UID should or should not be able to open the file, nor
should eCryptfs do such a thing.

Having eCryptfs impose additional access control onto the decrypted
file contents in a trusted host environment would provide no
additional security while introducing unintended usability issues. For
instance, a user may wish to share his decrypted files with certain
other users on the system without having to share his key with them or
add their keys to a set of keys wrapping the inode’s FEK. Users expect
to be able to accomplish such a task via users, groups, capabilities,
and types, and eCryptfs defers access control decisions on trusted
host environments to these existing access control mechanisms.

Q. «Unable to allocate crypto cipher with name
[---]; rc = [-2]«

Make sure that you have enabled the kernel crypto API and that you
have built the ciphers, hashes, and chaining modes that you wish to
use. This will usually be md5, aes, cbc, and ecb. Also, make sure that
the requested key size is valid for your cipher.

Q. «Error mounting eCryptfs; rc = [-2]; strerr = [No
such file or directory]«

Make sure that both the source and destination directories that you
provide to the mount command exist.

Q. «Error mounting eCryptfs; rc = [-22]; strerr =
[Invalid argument]«

Check your system log for the real problem.

Q. «ecryptfs_parse_options: Could not find key with
description: [deadbeaf...]"

If the mount fails and the message «ecryptfs_parse_options:
Could not find key with description: [deadbeaf...]" is in
your system logs, then there was a problem inserting your mount key
into your kernel user session keyring.

After a mount attempt, run keyctl_show. You should see
something like this:

# keyctl show
Session Keyring
       -3 lswrv----------     0     0  keyring: _uid_ses.0
        2 lswrv----------     0     0   _ keyring: _uid.0
892244932 lswrv----------     0     0       _ user: deadbeef...

Where deadbeef is the signature that corresponds with
your key. If you don’t see this, then there is a problem with your
keyring setup.

If you su to root, be sure to initiate the session by using the —
flag.

Finally, try linking your user keyring into your active session
keyring:

# keyctl link @u @s

Q. «ecryptfs_parse_packet_set: Expected
signature of size [8]; read size [7]«

Older versions of eCryptfs shipping in older kernels had a minor bug
where eCryptfs would only write out and read in 7 of the 8 key
signature characters to the metadata of the lower file. This violates
the eCryptfs spec, so newer versions of eCryptfs correct this bug and
refuse to read files that do not conform to the spec.

The current correctly implemented version of eCryptfs cannot read
files created with the early nonconformant and buggy release. If you
have any files created with the earlier version, you will need to boot
with the earlier version of eCryptfs and copy the decrypted files to
secure location (e.g., a loopback mount image protected with
dm-crypt). You will then need to copy the data from the secure
location into an eCryptfs mount using the most recent kernel release.

Note that the Versions of eCryptfs from 2.6.24 and on will be able to
read files created by earlier versions, back through to 2.6.24, as
indicated in the ecryptfs-utils package README file:

eCryptfs is still in a developmental stage. When you upgrade the
eCryptfs kernel module, it is possible that the eCryptfs file format
has been updated. For this reason you should copy your files to an
unencrypted location and then copy the files back into the new
eCryptfs mount point to migrate the files. File format version 3 and
beyond (in kernel version 2.6.24) is expected to remain readable,
however.

Q. My question isn’t answered here.

Ask a question on StackExchange.
File a bug on Launchpad.
Discuss an issue on the mailing list.