Regression in ecryptfs-recover-private

Bug #1723826 reported by Cefn
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I had given up trying to recover my encrypted home directory from my bootable USB key with ecryptfs-utils 111-0ubuntu5 and was encountering the error below. However, seems that a change in the ecryptfs-recover-private utility since version 107-0ubuntu1 was causing the intended mount folder not to be created.

Passphrase:
Inserted auth tok with sig [cc0ba99aac1dcfd8] into the user session keyring
mount: /tmp/ecryptfs.PTL9aYAz: mount(2) system call failed: No such file or directory.
ERROR: Failed to mount private data at [/tmp/ecryptfs.PTL9aYAz].

The invocation was as follows

sudo ecryptfs-recover-private /media/cefn/lubuntu-lexar/home/.ecryptfs/cefn/.Private/

...which prompts for the login passphrase, which seems to be accepted, but then leads to the failure to mount.

However, I tried running the same routine with the same USB key on an older machine (originally running Vivid Vervet 15.04 and currently with ecryptfs-utils version 107-0ubuntu1). On that system the identical procedure successfully mounts the encrypted folder, making me think it's a regression.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: ecryptfs-utils 111-0ubuntu4
ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
Uname: Linux 4.13.0-12-generic x86_64
ApportVersion: 2.20.7-0ubuntu1
Architecture: amd64
Date: Mon Oct 16 02:14:47 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2017-10-15 (0 days ago)
InstallationMedia: Lubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170926)
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Cefn (6-launchpad-net-cefn-com) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed
Revision history for this message
sebastian-s (sebastian-s) wrote :

I had the same issue.
I am trying to move my files from an old Linux Mint 18.2 home to my new Ubuntu 17.10 home.
Using the Ubuntu 17.10 Live CD I could mount both my Linux Mint as well as my Ubuntu encrypted homes.

For both installation I know the password and the passphrase.

On my up to date Ubuntu 17.10 I got the error.

$ sudo ecryptfs-recover-private /media/me/a1fe04d7-8591-0ee024c5b4a8/home/.ecryptfs/sebastian/.Private/INFO: Found [/media/me/a1fe04d7-8591-0ee024c5b4a8/home/.ecryptfs/oldme/.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 [9db6---81f] into the user session keyring
mount: /tmp/ecryptfs.WRoO9ZO5: mount(2) system call failed: No such file or directory.
ERROR: Failed to mount private data at [/tmp/ecryptfs.WRoO9ZO5].

Revision history for this message
sebastian-s (sebastian-s) wrote :

Running ecryptfs-utils, Version: 111-0ubuntu5

Revision history for this message
mprotic (mprotic) wrote :

Something to do with this one, perhaps (systemd regression) ?

https://bugs.archlinux.org/task/55943

https://bbs.archlinux.org/viewtopic.php?id=230834

Revision history for this message
mprotic (mprotic) wrote :
Revision history for this message
Cefn (6-launchpad-net-cefn-com) wrote :

I found a workaround for my case, which I encountered yet again in Bionic :(

Running the following command

keyctl link @u @s

...made the session keyring and the user keyring be linked. My interpretation is that one part of the routine tries to first put the key into the session keyring and then tries to use the user keyring to unlock it, which of course doesn't work. Surely this must be an easy fix to put in to the routine?

Lucas Levrel (llev)
tags: added: bionic
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.