> On Sun, Feb 15, 2015 at 05:21:19PM +0100, Christian Brauner wrote: > > Hello, > > > > I test the newest systemd from git on a regular basis by compiling it > > and installing it into a container and booting it. I did that with the > > several current systemd versions from git for the last couple of > > weeks. > > It seems that in the next version when booting a container with > > lxc-start, systemd creates a btrfs subvolume under > > > > rootfs/var/lib/machines > > > > in every container. This will cause lxc-destroy for unprivileged > > containers to > > fail. (Because subvolumes can currently be created but not destroyed > > by > > unprivileged users.) There either needs to be a way to destroy btrfs > > subvolumes > > for unprivileged user with lxc-destroy or the creation of btrfs > > subvolumes > > during container boot needs to be prevented. Is the second option > > already > > available? > > > > Best, > > Christian > > Add user_subvol_rm_allowed to your fstab and unprivileged users will be > able to remove subvolumes.
I have user_subvol_rm_allowed set. But it will fail nonetheless. lxc-destroy seems to expect that the rootfs is a btrfs subvolume. However, if it sees that rootfs itself is simply a folder and not a subvolume it will try to recursively delete it and then fail when it encounters a subvolume within the rootfs. (Systemd seems to create a btrfs subvolume only when the rootfs is a simple folder.) I think there should be some way of making lxc-destroy destroy all btrfs subvolumes within rootfs no matter if it is itself a subvolume or a simple folder. Sorry, this wasn't clear in my first mail. Christian
pgpwq07Qum6rW.pgp
Description: PGP signature
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
