lxc on top of fscrypt encrypted home breaks after 'fscrypt purge'

[dirtminer]

Expected behavior:
Unprivileged LXC will work in an encrypted home directory across reboot/purge
Actual behavior:
Need to 'modify' rootfs files or store them unencrypted.

I am using an encrypted home directory on Ubuntu 18.04 based on instructions at instructions at: tlbdk.github.io/ubuntu/2018/10/22/fscrypt.html
fscrypt 0.2.2-0ubuntu2.1 amd64 Tool for managing Linux filesystem encryption

Further, I can create an unprivileged LXC container in my home directory (for example)
lxc-create -t download -n httpd -- -d ubuntu -r trusty -a amd64
lxc-start -n httpd
lxc-attach -n httpd
This all works as expected.

This breaks after:

1. rebooting the system
2. 'fscrypt purge .' and logging out and back in.

lxc-start fails with the following error:
lxc-start: httpd: lxccontainer.c: wait_on_daemonized_start: 842 Received container state "ABORTING" instead of "RUNNING"
The log gives the following error:
lxc-start httpd 20190109202219.424 NOTICE start - start.c:start:2025 - Exec'ing "/sbin/init"
lxc-start httpd 20190109202219.424 ERROR start - start.c:start:2028 - Required key not available - Failed to exec "/sbin/init"

f I run the following command, I can again run the LXC instance:
lxc-usernsexec -m b:0:231072:65536 -- chroot .local/share/lxc/httpd/rootfs /usr/bin/find . -exec touch {} \;

[ebiggers]

I'm guessing this is a duplicate of #128, caused by the user's keyring not being available in the container. This will be fixed by switching to the filesystem-level keyrings with Linux v5.4+ and #148.

[ebiggers]

The solution to this problem was merged in #148, so I'm closing this.

However, due to the prerequisite of kernel v5.4 or later, the fix is currently "opt-in" via a setting in /etc/fscrypt.conf. See the new Troubleshooting section for how to enable it.

#182 tracks making new installations of fscrypt use v2 encryption policies by default when kernel support is detected.