Decrypt user home after installing Ubuntu 22.04

Question

I have a laptop with two mount points, one with the system (/) and another with the /home folder. My user folder in /home was encrypted with Ubuntu 20.04.

This morning I re-installed the system with the new Ubuntu 22.04 ISO. I formatted the system partition and let the /home partition be. I provided the same user name and password as explained in this earlier answer.

On log in Ubuntu 22.04 is not decrypting the user home folder. Most applications fail to start as they are not able to write in the user home.

I have both the log-in password and the passphrase necessary to decrypt the home folder. Therefore I tried to decrypt the folder manually, but ecryptfs-recover-private returns an error (see below).

How can I mount the user home folder encrypted by Ubuntu 20.04?

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

Update: I found an old thread at the Arch Linux forum reporting a similar issue and providing a workaround, manually mounting the encrypted volume. This method succeeds in mounting the volume and showing the contents of the folder tree root, but it does not provide access to any files or folders. Log below, changing dir, listing or copying any of the contents in mnt/bck fails.

# cd /home/.ecryptfs/lads/.ecryptfs
ecryptfs-unwrap-passphrase ./wrapped-passphrase
Passphrase:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ecryptfs-add-passphrase --fnek
Passphrase:
Inserted auth tok with sig [aaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbb] into the user session keyring
mount -t ecryptfs /home/.ecryptfs/lads/.Private /mnt/bck
Select key type to use for newly created files:

tspi
passphrase

Selection: 2
Passphrase:
Select cipher:

aes: blocksize = 16; min keysize = 16; max keysize = 32
blowfish: blocksize = 8; min keysize = 16; max keysize = 56
des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
twofish: blocksize = 16; min keysize = 16; max keysize = 32
cast6: blocksize = 16; min keysize = 16; max keysize = 32
cast5: blocksize = 8; min keysize = 5; max keysize = 16

Selection [aes]:
Select key bytes:

16
32
24

Selection [16]:
Enable plaintext passthrough (y/n) [n]: n
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [aaaaaaaaaaaa]: bbbbbbbbbbbb
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=bbbbbbbbbbbb
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=aaaaaaaaaaaa
Mounted eCryptfs
ls /mnt/bck | grep git
git
ls -la /mnt/bck/git
ls: cannot access '/mnt/bck/git': No such file or directory
cp /mnt/bck/.bash*
ls: cannot access '/mnt/bck/.bash_aliases': No such file or directory
ls: cannot access '/mnt/bck/.bash_history': No such file or directory
ls: cannot access '/mnt/bck/.bash_logout': No such file or directory
ls: cannot access '/mnt/bck/.bashrc': No such file or directory

Answer 1

The day after I ran the recipe posted at the ArchLinux forum I logged on again with the original Ubuntu 20.04 user account and realised the folder had been decrypted. The manual unwrapping of the passphrase possibly did it. Since it is not easy to repeat the process to understand at exactly which stage the home folder became accessible, below I post the full procedure. It requires the original user log-in password of to the 20.04 system.

1. Create a new user. Since Ubuntu 22.04 does not automatically decrypt the user home folder, most applications will function poorly or not function at all, I created a new system user to execute the rescue.

2. Unwrap passphrase and mount. After logging in with the rescue user execute the commands below. Replace user with the user name on the 20.04 system. Answer with the default to all queries posed by mount, except to "Enable filename encryption?". Answer "yes" to that query and enter the counterpart provided by the ecryptfs-add-passphrase command (bbbbbbbbbbbb in the example).

$ sudo apt install ecryptfs-recover-private ecryptfs-utils
$ sudo mkdir /mnt/bck
$ sudo su
cd /home/.ecryptfs/user/.ecryptfs
ecryptfs-unwrap-passphrase ./wrapped-passphrase
Passphrase:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ecryptfs-add-passphrase --fnek
Passphrase:
Inserted auth tok with sig [aaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbb] into the user session keyring
mount -t ecryptfs /home/.ecryptfs/user/.Private /mnt/bck
Select key type to use for newly created files:

tspi
passphrase

Selection: 2
Passphrase:
Select cipher:

aes: blocksize = 16; min keysize = 16; max keysize = 32
blowfish: blocksize = 8; min keysize = 16; max keysize = 56
des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
twofish: blocksize = 16; min keysize = 16; max keysize = 32
cast6: blocksize = 16; min keysize = 16; max keysize = 32
cast5: blocksize = 8; min keysize = 5; max keysize = 16

Selection [aes]:
Select key bytes:

16
32
24

Selection [16]:
Enable plaintext passthrough (y/n) [n]: n
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [aaaaaaaaaaaa]: bbbbbbbbbbbb
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=bbbbbbbbbbbb
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=aaaaaaaaaaaa
Mounted eCryptfs

3. Check mount and regain access. With the volume mounted, check if you can read its contents, e.g. ls -la /mnt/bck. You won't be able to drill down the folder tree or copy files, but that is fine. Log out with the rescue user and log back on with the original 20.04 user, you should now have full access to your home folder.

P.S.: Creating the rescue user might not be necessary, if you manage to launch a root session (e.g. sudo su) it might be possible to run everything from there. But at this point I can no longer test that.