All right, that makes sense — thanks for clearing this up!
** Changed in: lxc (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1657437
Title:
Unprivileged containers run by non-root fail to start if trying to
bind-mount a directory that contains a mounted ecryptfs
Status in lxc package in Ubuntu:
Invalid
Bug description:
Not sure if this is an lxc bug or an ecryptfs bug. Please reassign if
necessary.
I have an unprivileged container that is defined in the default
location, ~/.share/local/lxc. It bind-mounts the host's /home
directory to /home inside the container, like so:
lxc.mount.entry = /home home none bind 0 0
My /home directory contains an ecryptfs at ~/.Private, which is
mounted to ~/Private with default options, at login, via pam_ecryptfs.
lxc-start then results in the following error showing up in the log
file:
lxc-start 20170118124950.117 ERROR lxc_utils -
utils.c:safe_mount:1746 - Invalid argument - Failed to mount /home onto
/usr/lib/x86_64-linux-gnu/lxc/home
lxc-start 20170118124950.117 ERROR lxc_conf -
conf.c:mount_entry:1650 - Invalid argument - failed to mount '/home' on
'/usr/lib/x86_64-linux-gnu/lxc/home'
lxc-start 20170118124950.117 ERROR lxc_conf - conf.c:lxc_setup:3790
- failed to setup the mount entries for 'trusty-edx-devstack'
lxc-start 20170118124950.117 ERROR lxc_start - start.c:do_start:826
- Failed to setup container "trusty-edx-devstack".
lxc-start 20170118124950.117 ERROR lxc_sync - sync.c:__sync_wait:57
- An error occurred in another process (expected sequence number 3)
lxc-start 20170118124950.118 ERROR lxc_start -
start.c:__lxc_start:1338 - Failed to spawn container "trusty-edx-devstack".
lxc-start 20170118124955.668 ERROR lxc_start_ui -
tools/lxc_start.c:main:360 - The container failed to start.
Unmounting the ecryptfs allows the container to start normally. After
the container has been started, the ecryptfs can be remounted with
ecryptfs-mount-private, which appears to have no ill effect on the
container.
I don't quite see why the mounted ecryptfs would prevent /home from
being bind-mounted into the container. After all, bind-mounting /home
to some other mount point in the host works just fine — with the
Private directory simply being empty, save for the Access-Your-
Private-Data.desktop and README.txt symlinks, in the bind mount
location. This is also what happens in privileged containers whose
configuration has the same lxc.mount.entry.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1657437/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
