Snapd inside LXC

“snap install” originally gave me:

error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
   /tmp/sanity-squashfs-391078372: failed to setup loop device: No such file or directory

I fixed that by adding “lxc.cgroup.devices.allow = b 7:* rwm” to the container config and running “mknod -m 0660 /dev/loop0 b 7 0” inside it. Then I got:

error: system does not fully support snapd: fs.may_detach_mounts kernel parameter is supported but disabled

I fixed that by copying /usr/lib/sysctl.d/99-snap.conf from guest to host and running “sysctl -p /usr/lib/sysctl.d/99-snap.conf” on the host. Now I’m stuck at:

error: cannot perform the following tasks:
- Setup snap "core" (8039) security profiles (cannot setup udev for snap "core": cannot reload udev rules: exit status 2
udev output:
)
- Setup snap "core" (8039) security profiles (cannot reload udev rules: exit status 2
udev output:
)

No idea what to do about that. Host & guest are CentOS 7. Thank you.

1 Like

Just try running the install again, when getting those udev errors in privileged containers, the second try usually succeeds.

While running the install a second time does get me past those errors for core, I just get the same errors for the snap I am actually trying to install, no matter how many times I try it:

# snap install --devmode --beta anbox
error: cannot perform the following tasks:
- Setup snap "anbox" (158) security profiles (cannot setup udev for snap "anbox": cannot reload udev rules: exit status 2
udev output:
)
- Setup snap "anbox" (158) security profiles (cannot reload udev rules: exit status 2
udev output:
)
- Setup snap "anbox" (158) security profiles for auto-connections (cannot setup udev for snap "anbox": cannot reload udev rules: exit status 2
udev output:
)
- Setup snap "anbox" (158) security profiles for auto-connections (cannot reload udev rules: exit status 2
udev output:
)

The anbox snap is kinda special to be able to run in a LXC container.

When you install a snap package with --devmode, the snap package behaves like a deb package and has full access to the computer. However, inside an unprivileged LXC container, the snap package does not get the full access to the computer and fails to install.

CentOS 7 does not support unprivileged containers

That’s not true, you can make unprivileged containers work on Centos 7 just fine.
We actually test this every day with the LXD snap.

You do need to dig into their documentation a bit to find the right kernel options to allow the user of the user namespace though.

CentOS 7 out of the box does not support unprivileged containers, therefore I am not using them.

For the specific case of getting to install/run anbox in a LXC container, you definitely cannot do this in an unprivileged container.

The anbox project uses the snap packaging as a container for their software. You must install this one with --devmode which means that there is no confinement or other security features.

Having said that, if you eventually get anbox to install in a privileged container, you need to then set up the container so that the GUI output from the container will appear on the host.

For the specific case of anbox, it makes sense to install directly on the host.

The host does not have a GUI. Various containers have GUIs using Xvnc, including the one I’m trying to install anbox into.

I am attempting to install anbox into a privileged container.

I just figured out that /var/log/messages receives errors during an anbox install attempt:

Nov 29 10:05:16 anbox systemd: Starting Snappy daemon...
Nov 29 10:05:16 anbox snapd: AppArmor status: apparmor not enabled
Nov 29 10:05:16 anbox snapd: daemon.go:346: started snapd/2.42.1-1.el7 (series 16; classic; devmode) centos/7 (amd64) linux/3.10.0-1062.4.1.el7.x86_6.
Nov 29 10:05:16 anbox snapd: daemon.go:439: adjusting startup timeout by 35s (pessimistic estimate of 30s plus 5s per snap)
Nov 29 10:05:16 anbox systemd: Started Snappy daemon.
Nov 29 10:05:16 anbox snapd: api.go:952: Installing snap "anbox" revision unset
Nov 29 10:05:21 anbox systemd: Reloading.
Nov 29 10:05:21 anbox systemd: /usr/lib/systemd/system-generators/snapd-generator failed with error code 1.
Nov 29 10:05:21 anbox systemd: Mounting Mount unit for anbox, revision 158...
Nov 29 10:05:21 anbox systemd: Mounted Mount unit for anbox, revision 158.
Nov 29 10:05:23 anbox systemd: Reloading.
Nov 29 10:05:23 anbox systemd: /usr/lib/systemd/system-generators/snapd-generator failed with error code 1.
Nov 29 10:05:26 anbox systemd: Reloading.
Nov 29 10:05:26 anbox systemd: /usr/lib/systemd/system-generators/snapd-generator failed with error code 1.
Nov 29 10:05:27 anbox systemd: Reloading.
Nov 29 10:05:27 anbox systemd: /usr/lib/systemd/system-generators/snapd-generator failed with error code 1.
Nov 29 10:05:27 anbox snapd: handlers.go:460: Reported install problem for "anbox" as already-reported

Trying to use snap in Ubuntu 20.04 inside LXD/LXC:

snap install go --classic
error: too early for operation, device not yet seeded or device model not acknowledged

How to solve this?

UPD: I have this errors only in nested containers (host/container/container). In normal containers (host/container) all works fine.

snapd cannot work in nested containers, it’s a hard limitation of apparmor namespaces that they do not nest currently so while other things usually mostly behave in nested containers (so long as they don’t need too much from apparmor), snaps will not.

There are a few very ugly tricks you can do to still make them work, but it effectively causes apparmor to be completely disabled in that nested container, seriously compromising security of any snap you run in there.