Encryption Broken with ChromeOS Update

[D0nvt]

Please describe your issue:

Once again with new ChromeOS updates - this time Version 61.0.3163.120 (Official Build) (64-bit) - my encrypted chroots are failing to start. I run all chroots off my SD card (128 GB), with /mnt/stateful_partition/crouton/ symlinked to a directory there.

Running either of the following for trusty or kali:
$(CROUTON)/bin/startxfce4 -n trusty
$(CROUTON)/bin/enter-chroot -n trusty

Results in (ellipsis added):
mount: mount(2) failed: /run/crouton/media/removable/...../chroots/trusty: No such file or directory
Failed to mount trusty.

Updating chroot does not resolve this, nor does installing a fresh chroot.

Apologies for essentially reopening #3262 - but I didn't see an open issue relating to this, and that one has already been marked resolved.

Output of sudo edit-chroot -all:
$ sudo sh /media/removable/..../bin/edit-chroot -all
name: kali
encrypted: yes, locked
Unmounting /media/removable/..../chroots/kali...
name: trusty
encrypted: yes, locked
Unmounting /media/removable/..../chroots/trusty...

[kapilhp]

While I do not have an identical problem, the cause of this problem may be similar. I am running Debian "buster". In my case, the encrypted chroot mounts. However, I have another encryptfs file system on an external drive for use within the chroot. When I try to mount that I get the same error message as the OP. This message too started after the update to 61 and continues with 62.

In my case, after trying the "encryptfs-mount-private" command a few times, I did an "sudo encryptfs-recover-private /path/to/encryptfs/dir" and after some trials, it eventually did mount! After that it worked stably until the next time I stopped/started the chroot. Again, it would take a little while and after a few tries it "settled" down and stopped giving the error message.

Bottom line: The error did not seem to be deterministically repeatable! So that would say some sort of delay in starting the "encrypfsd" daemon or its response time.

Update: (21 Nov 17) As suggested in #3246, #3278, #3247, one needs to create a new key session before running the mount command. Replacing the /sbin/mount.ecryptfs_private line with keyctl session - sh -c 'keyctl link @u @s;/sbin/mount.ecryptfs_private' in the ecryptfs-mount-private script allowed the mount to go through smoothly.

[kapilhp]

Perhaps OP could check if the "mount-chroot" command is able to mount his chroot. Something like:
sudo mount-chroot mychroot
This can be followed with:
sudo unmount-chroot mychroot
to unmount the mounted chroot at the end.

If "mount-chroot" works, then one should be able to start crouton after running it.

[D0nvt]

Unfortunately, mount-chroot results in the same "mount: mount(2) failed:..." error as before

[iams-wu]

mount: mount(2) failed: /run/crouton/media/removable/drive/chroots/xenial: No such file or directory
Failed to mount xenial.

Just here to confirm also the same problem. The problem occurs on multiple different computers.

The patch from #3278 is already present -- so this issue is entirely separate

[iams-wu]

sudo ecryptfs-mount-private /media/removable/drive/chroots/xenial

results in:

ERROR: Encrypted private directory is not setup properly

[kapilhp]

@yithump @D0nvt

Is either of you, by any chance, using a directory for storing the files that is already encrypted?

While testing this out, I found that ecryptfs does not like to encrypt directories that have already been encrypted. It generates numerous levels of mysterious messages (on console, in logs) which do not say this but mean this.

As a (only one!) data point, I did a fresh install via crouton of xenial on an SD card and I did not run into this issue after I had diagnosed and fixed the double encryption problem. (Which had me confused for a while...)

Kapil.

[D0nvt]

I had some encrypted files, but none on trusty if I remember correctly. I finally did a full reinstall on the latest Chrome update though and can confirm encrypted kali-rolling works. Trusty with xfce failed when the http service stopped (the same error I've seen when trying to update trusty before), but I'll try it with some others.

[D0nvt]

I'm not sure exactly which update resolved this (it was at least a couple weeks ago), but I've been able to use encrypted chroots for both trusty and kali-rolling. Currently at 63.0.3239.140 (Official Build) (64-bit). I'll mark this as closed - if this resurfaces, see the comment by @kapilhp above regarding resetting your key session.