21

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.

$ sudo ecryptfs-recover-private /BLAH/.Private
INFO: Found [.Private/].
Try to recover this directory? [Y/n]: 
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] 
INFO: Enter your LOGIN passphrase...
Passphrase: 
Inserted auth tok with sig [BLAH] into the user session keyring
mount: mount(2) failed: No such file or directory
ERROR: Failed to mount private data at [/tmp/ecryptfs.NcWkVmQ5].

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.

Thoughts?

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

Improve this question

6 Answers 6

Reset to default
10

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

In detail:

# sudo -i
# ecryptfs-add-passphrase --fnek 
Inserted auth tok with sig [aaaaaaaaaaaaa] into the user session keyring 
Inserted auth tok with sig [bbbbbbbbbbbbb] into the user session keyring  
# mkdir -p /mnt/new_mount_point  
# mount -t ecryptfs /mnt/old_mount_point/home/username/.Private /mnt/new_mount_point
  • 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
Improve this answer
5
  • 2
    this worked for me but there is a final question after the filename encryption which asks for the FNEK signature to use, defaulting to the first auth tok in the output from ecryptfs-add-passphrase --fnek. I found I had to use the 2nd one instead.
    – darrend
    Apr 8, 2019 at 0:58
  • This. The only method that works for me is to open the ubuntu community wiki linked above, and follow the instructions.
    – fdierre
    May 3, 2019 at 20:52
  • 1
    This worked for me! I followed the "Recovering Your Data Manually" instructions directly, as you indicated, here: help.ubuntu.com/community/…. Just remember that if you need to follow the section "Recovering Your Mount Passphrase" as well, you need to use sudo, even though they don't mention it. ie: instead of ecryptfs-unwrap-passphrase /home/username/.ecryptfs/wrapped-passphrase, do sudo ecryptfs-unwrap-passphrase /home/.ecryptfs/username/.ecryptfs/wrapped-passphrase (notice also the slightly different path I used).
    – Gabriel Staples
    Jul 13, 2019 at 1:29
  • 2
    This solution appears to be incomplete as of today. There's at least one more question : Filename Encryption Key (FNEK) Signature [XYZ]: and I have no idea what this signature is... @Martin's solution (askubuntu.com/a/679565/924202) did it for me. :-)
    – breversa
    Jan 26, 2020 at 16:55
  • 1
    In the result it "mounted" to a specified directory, but only file listing worked. Actual file data was unavailable (No such file or directory ) while filenames were visible.
    – Artfaith
    Dec 8, 2021 at 6:24
10

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

sudo ecryptfs-insert-wrapped-passphrase-into-keyring /BLAH/.ecryptfs/wrapped-passphrase
sudo ecryptfs-recover-private /BLAH/.Private
Improve this answer
3
  • sudo is required on the first command too (ecryptfs-insert-wrapped-passphrase-into-keyring) or else I get the following error! Error: Unwrapping passphrase and inserting into the user session keyring failed [-5] Info: Check the system log for more information from libecryptfs
    – Gabriel Staples
    Jul 11, 2019 at 6:32
  • 5
    ...but unfortunately the 2nd command (sudo ecryptfs-recover-private /BLAH/.Private) still fails for me. :( mount: /tmp/ecryptfs.aLkDeiWo: mount(2) system call failed: No such file or directory. ERROR: Failed to mount private data at [/tmp/ecryptfs.aLkDeiWo].
    – Gabriel Staples
    Jul 11, 2019 at 6:35
  • This worked for me as well. Apparently, there's an open bug since 2018 with a hacky fix, but still not corrected : bugs.launchpad.net/ecryptfs/+bug/1769373
    – breversa
    Jan 26, 2020 at 16:52
6

For me this worked, as discussed on ecryptfs-mount-private fails to initialize ecryptfs keys:

sudo keyctl link @u @s
sudo ecryptfs-recover-private .Private
Improve this answer
1
2

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

Improve this answer
1
  • Ah, the oldest trick in the book! Good to know.
    – lnmaurer
    Dec 9, 2015 at 15:36
1

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

Improve this answer
3
  • I think I have a very similar problem, but not sure how you did solve it... Do you mind having a look at my new post? Thanks! askubuntu.com/questions/1035424/…
    – Matifou
    May 12, 2018 at 22:54
  • Hi, Matifou! What do you have in your syslog right after the attempt to do ecryptfs-recover-private /home/.ecryptfs/old_user/.Private ?
    – Yaroslav Fedorina
    May 14, 2018 at 10:07
  • Hey! If you have problems with the key (see dmesg or syslog), e.g. Could not find key with description: [XXX] process_request_key_err: No key Could not find valid key in user session keyring for sig specified in mount option: [XXX] then, try adding the passphrase manually: Option "1" in /usr/bin/ecryptfs-manager It helped me.
    – Yaroslav Fedorina
    May 14, 2018 at 11:28
0

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/

To elaborate:

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

    $ cd /mnt/sda5/home 

    $ ls -lag .ecryptfs/guy/
        drwxr-xr-x  4 guy    4096  .
        drwxr-xr-x  3 root   4096  ..
        drwx------ 16 guy    4096  .Private
        drwx------  2 guy    4096  .ecryptfs


    $ ls -lag .ecryptfs/guy/.ecryptfs/
        drwx------ 2 guy 4096 Jan 1 00:12 .
        drwxr-xr-x 4 guy 4096 Jan 1 00:11 ..
        -rw------- 1 guy   13 Jan 1 00:11 Private.mnt
        -rw------- 1 guy   34 Jan 1 00:11 Private.sig
        -rw-r--r-- 1 guy    0 Jan 1 00:11 auto-mount
        -rw-r--r-- 1 guy    0 Jan 1 00:11 auto-umount
        -rw------- 1 guy   58 Jan 1 00:12 wrapped-passphrase

    #This were the data are stored

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

    $ ls -lag guy/
   lrwxrwxrwx 1 root     28 Jan 2 15:52 .Private  -> /home/guy/.Private
   lrwxrwxrwx 1 root     29 Jan 2 15:49 .ecryptfs -> /home/guy/.ecryptfs

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:

    $ ls -lag guy/
    dr-x------ 2 guy 4096 Jan 2 15:52 .
    drwxr-xr-x 6 root   4096 Jan 1 00:11 ..
    lrwxrwxrwx 1 root     28 Jan 2 15:52 .Private -> ../.ecryptfs/guy/.Private
    lrwxrwxrwx 1 root     29 Jan 2 15:49 .ecryptfs -> ../.ecryptfs/guy/.ecryptfs
    lrwxrwxrwx 1 guy   56 Jan 1 00:11 Access-Your-Private-Data.desktop -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop
    lrwxrwxrwx 1 guy   52 Jan 1 00:11 README.txt -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt

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

    $ cd /mnt/sda5/home 
    $ cd guy
    $ sudo unlink .Private
    $ sudo unlink .ecryptfs 
    $ sudo ln -sr ../.ecryptfs/guy/.Private
    $ sudo ln -sr ../.ecryptfs/guy/.ecryptfs

After you can mount manually the home directory manually or using

 cd /mnt/sda5/home 
 sudo ecryptfs-recover-private .ecryptfs/guy/.ecryptfs/.Private

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

Improve this answer

You must log in to answer this question.

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