Recover your locked files on an encrypted Linux partition

And why it could be a bad idea to encrypt your whole disk

If you want to see how you can fix your issue with eCryptfs ASAP, jump directly to the next section.

Boohoo my files are locked down 😭️ (Photo by Andrea Piacquadio from Pexels)

Lately, I was updating my laptop to Linux Mint 20 “Ulyana” (very good Linux distribution, by the way). I did some backups with Timeshift, as requested in the installation notes, and processed the update.

Unfortunately, I wasn’t really satisfied with the upgrade since:

• it had reset my Trackpoint settings and it’s a real pain to configure well,
• the process required me to remove many foreign packages installed from PPAs (like Vivaldi, VSCode or PHP, that I use constantly) so I needed to reconfigure the PPAs and reinstall all the packages,
• many installed packages were not useful anymore but it seemed hard to clean up because some of these packages had strong hidden dependencies in the system that I couldn’t figure out at first glance.

So, I made a new backup and wanted to roll back to a previous system snapshot.

“I will get back to the upgrade another time”, I thought.

And how stupid I was…

Distro upgrades are the worst, and my experience has taught me that there is always a thing that messes up everything. This exact consideration made me abandon Linux several years ago and to turn to Windows (yeah, it happens). Why? Because of the time spent on administrative tasks. Linux is awesome, but regularly doing maintenance makes it really unproductive.

Anyway! Back to the matter at hand. When I restored the previous snapshot of the system, I knew if something went wrong at this point, really bad things would happen. And it happened: the restoration process stopped in the middle and backed me up to the desktop.

“Oh boy… Not now, please god please, not now, please please please!!!”

At this point, what can you do? Wait and see what would happen? I did. And then? Cross your fingers and reboot? That’s clearly the last thing to do. I should have better-checked things before, but I knew it was already nasty.

I rebooted and…

“Grub is dead. Shit. And my whole disk is encrypted. And I need to recover my data. That’s gonna be fun.”

Steps I did to recover my encrypted data

I put a Live USB key on with Elementary on it, started it up and tried to mount my system partition (for me, it was /dev/sda5 ; if you don’t know what is the partition you need to mount, use Gparted or fdisk):

elementary@elementary$ sudo mount /dev/sda5 mint/
mount: /home/elementary/mint : unknown « crypto_LUKS » filesystem type.

Ok…

Now, let’s push the forward button to save you several hours of googling, testing, and messing things up, and let’s give you the actual solution (that worked for my specific case). First, let’s make us root:

elementary@elementary$ sudo su
root@elementary#

And ensure we have the right tools and modules loaded:

root@elementary# apt install lvm2 cryptsetup ecryptfs-utils
root@elementary# modprobe dm-crypt

We need to open our encrypted partition and give it a name. I chose mint because, obviously, it has Linux Mint on it.

root@elementary# cryptsetup open --type luks /dev/sda5 mint

It will ask for your passphrase. Yeah, the passphrase you used to encrypt your drive. This one. So enter it.

All good? Cool, now you need to scan the LVM2 volumes that are accessible:

root@elementary# vgscan
  Reading volume groups from cache.
  Found volume group "mint-vg" using metadata type lvm2

It found a mint-vg volume group. Let’s activate it:

root@elementary# vgchange -ay mint-vg
  2 logical volume(s) in volume group "mint-vg" now active

We now need to find the partition name that is interesting us:

root@elementary# lvs
  LV     VG      Attr       LSize
  root   mint-vg -wi-a-----  236,80g
  swap_1 mint-vg -wi-a-----  980,00m

For me, it’s named root, but it could differ for you according to your installation. Let’s mount it!

root@elementary# mkdir mint
root@elementary# mount /dev/mint-vg/root mint/

An ls on the mounted mint/ directory shows me that everything went well as I can see the usual root directories like /dev, /proc, /sys and so on. But a cd to my personal home directory throws an error to me, because it is encrypted too (yes, initially my system required me to enter the passphrase at boot up, and also to log in to my account).

To recover our home we’ll need another tool (please adapt <username> to your case). It will ask to another passphrase which should be the one you used to login to your account:

root@elementary# ecryptfs-recover-private --rw mint/home/.ecryptfs/<username>/.Private/
INFO: Found [mint/home/.ecryptfs/pyrsmk/.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 [3ce4c488be78156a] into the user session keyring
mount: /tmp/ecryptfs.zfcHznz2 : échec de l’appel système mount(2) : Aucun fichier ou dossier de ce type.
ERROR: Failed to mount private data at [/tmp/ecryptfs.zfcHznz2].

It seemed it didn’t work. But in fact, it comes from a weird behavior of the eCryptfs tools that can be fixed by typing:

root@elementary# ecryptfs-manager

And exiting it directly by choosing the 4 option.

Now, let’s try again:

root@elementary# ecryptfs-recover-private --rw mint/home/.ecryptfs/<username>/.Private/
INFO: Found [mint/home/.ecryptfs/pyrsmk/.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 [3ce4c488be78156a] into the user session keyring
INFO: Success!  Private data mounted at [/tmp/ecryptfs.sLsBBVmV].

It worked! Yay!

root@elementary# cd /tmp/ecryptfs.bYXuxPIM/
root@elementary# ls

It lists my personal files as expected. Now I can backup them on another drive and reinstall the system.

Epilogue

At the time, I encrypted my whole disk for security and privacy reasons in the unfortunate case where I lose my laptop. But some trade-offs are coming with this.

Encryption slows down I/O (especially with eCryptfs), that’s why it’s recommended to only encrypt your home instead of the whole disk. But it’s only true when there’s no sensitive data on, for example, your /etc directory.

I would also underline the fact that encryption is especially needed for professional activities as the data is clearly more sensitive. A malicious person could have access to the credentials saved on your .profile file, to private repositories with even more sensitive information (if things are not done well), or even commit code with your own identity if you have no GPG key to sign your commits (and push them if your SSH key is compromised).

So…

Stay safe 🙃️.

Update 08/02/2020: many of you have noticed that I had double encryption in place, full disk encryption on one hand and my home with eCryptfs on the other hand. I don’t remember how I ended in that state, but it surely is counter-productive.

Update 08/03/2020: eCryptfs is deprecated and should not be used anymore.

Update 08/09/2020: the author of eCryptfs has left a detailed comment on the state of its file system.