[lxc-devel] Systemd creates btrfs subvolume under /var/lib/machines and makes lxc-destroy fail

[Christian Brauner]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150216/75a80d85/attachment.sig>