Recovering with live-CD failed

Asked by syscon-hh

As described in the documentation

I tried to recover my data on a crashed ubuntu jaunty system with a jaunty live-system (with a known Passphrase - which has been verified with the approbiate command additionally) . Mounting the crashed system to /mnt and typing into a terminal:

sudo mount -t ecryptfs /mnt/home/<username>/.Private /opt

has mounted the folder .Private to /opt, but the foldername and filename are not readable (not decrypted) - the content itself will be readable by editor as i.e nano.

Whats going wrong, I tried all different solutions given, especially "enable plantext passthrough" (y/n [n]) as well as "enable foldername decryption" (y/n [n]), it's ending always in the same desaster.

On the other hand, an older System (Intrepid Ibex) with the folder ~/Private the above commands decryptes the content of the folder, due to the circumstance foldernames and filenames are plantext.

Please notice: The output of the above command has changed - the description should be adopted to the new scheme/form.

Question information

English Edit question
Ubuntu ecryptfs-utils Edit question
No assignee Edit question
Solved by:
Last query:
Last reply:
Revision history for this message
Sam_ (and-sam) said :

Could it be because not using the original procedure?
sudo mount -t ecryptfs /home/username/.Private /home/username

Similar here:

Last exit - file a bug

Revision history for this message
syscon-hh (syscon-kono) said :

Thank You for answering - no, that's what I tried first. The result is the same - no decryption of file- or foldernames.

For further information - this happens with a clean System as well - normal login decrypted correct and an extern trial fails, but (so good) destroys nothing.

To file a bug is intended, but own misshandling I would exclude first!

Revision history for this message
Sam_ (and-sam) said :

Sorry, for not being very helpful.
Your entry didn't sound like you try to exclude own misshandling.
Seems no one yet tried to recover this way, but #371719 in the list below slightly gives a hint what might be possible in the future:

Revision history for this message
syscon-hh (syscon-kono) said :

Hi Sam and to all are interested in a solution - I did it my way! Following <user> is the name/owner of the crashed system home.

Starting a Live-System (CD/DVD or USB-Stick) and on 'ubuntu'-Desktop using a Terminal:

sudo su
adduser <user> # provide same name and login-password as origin
adduser <user> admin
# (test it by logout 'ubuntu' and login <user> and come back to 'ubuntu')
mount -t /dev/sda3 /mnt '# crashed system partition with /home !
ln -s /mnt/var/lib/ecryptfs /var/lib/ecryptfs # creates folder with content inside 'ubuntu'
cd /home/<user>
rm -rf *
rm -rf .* # delete all inside these <user> folder !!
ln -s /mnt/var/lib/ecryptfs/<user> .ecryptfs
ln -s /mnt/home/<user>/.Private
# logout 'ubuntu' and login <user> and be happy!!

Revision history for this message
Sam_ (and-sam) said :

Congratulations and thanks for reporting the solution.
Just in order to understand it correctly, one will remove it's 'original' /home/user but restore it's ecryptfs (Private folder) via symlink from /var/lib, hence a backup from all the other content of /home/user is (as always) recommended in case to restore it?

Revision history for this message
syscon-hh (syscon-kono) said :

The line above -> cd /home/<user> points to the 'new' created user inside 'ubuntu' live-system and these content inside this folder should be deleted, only -not the content of the "mounted" system (crashed one). The message using remove-command response 'not be able to delete ...' ,can be ignored!

The next step 'links' to the data to be recovered, hopfully successfully.

Revision history for this message
Sam_ (and-sam) said :

Thanks for the clarification.

Revision history for this message
syscon-hh (syscon-kono) said :

So I created the bug-report #383059 for investigations and clarification, if interested, You may confirm.

Revision history for this message
syscon-hh (syscon-kono) said :
Revision history for this message
Alex Beels (arbeels-ossf) said :

Here is an alternate way to mount a backup of your encrypted Home directory. It is based on Dustin Kirkland's suggestion in one of of his posts to Bug#455709, with some simplifications.

This method requires you to be root, but it will work from any system with ecryptfs installed (i.e. does not need a LiveCD) and only requires a backup of your .Private directory and your passphrase. Note that you can use this to do a read-only mount of a backup on read-only media, if you want.

In the transcript below, <passphrase> is the passphrase for your encrypted home directory (usually 32 hex characters).
In the mount command, "yyyyyyyyyyyyyyyy" is the second key listed by ecryptfs-add-passphrase.

ubuntu@ubuntu$ sudo su
root@ubuntu:~# keyctl clear @u
root@ubuntu:~# keyctl list @u
(should be empty)
root@ubuntu:~# ecryptfs-add-passphrase --fnek
Passphrase: <passphrase>
Inserted auth tok with sig [xxxxxxxxxxxxxxxx] into the user session keyring
Inserted auth tok with sig [yyyyyyyyyyyyyyyy] into the user session keyring
root@ubuntu:~# mount -t ecryptfs -o ecryptfs_fnek_sig=yyyyyyyyyyyyyyyy,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /backuppath/.Private /mnt/recovered
Passphrase: <passphrase>
Enable plaintext passthrough (y/n) [n]: n
Attempting to mount with the following options:
Mounted eCryptfs

*** IMPORTANT *** If you do not specify "ecryptfs_fnek_sig=yyyyyyyyyyyyyyyy" in the mount command, you will be aked if you want to enable filename encryption. Answer "y". You will then be asked for a FNEK signature. Be sure that you manually enter the second key from ecryptfs-add-passphrase. As of ecryptfs-utils version 81-0, the prompt will mistakenly offer the first key as a default. This is an error. Ignore the default.