many systemd units failing in oracular LXD containers

Nick Rosbrook nick.rosbrook at canonical.com
Mon Jul 15 14:34:51 UTC 2024


Hello,

tl;dr - If e.g. systemd-resolved (among many other systemd services)
fails to start in oracular LXD containers, configure your container
with security.nesting=true (safe for unprivileged containers only).

I wanted to raise awareness of a bug[1] and its workaround because
many people are likely to hit it. The bug is that in LXD containers,
systemd units with credentials[2] will fail to start because setting
up credentials requires bind mounts which are prevented by LXD's
default AppArmor policy. The bug is not new, but in systemd v256 (now
in oracular), many of systemd's own services utilize credentials in
some way, so the bug is more apparent. Most notable is
systemd-resolved.

The LXD team has been very helpful and we are working on resolving
this in LXD. One possibility is that by default, unprivileged (already
the default) LXD containers will have security.nesting=true[3], which
allows more mounts like the ones systemd is attempting. So, in the
mean time, the workaround for this is to configure your *unprivileged*
(this is not safe for privileged containers) containers with
security.nesting=true.

Thanks,
Nick

[1] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2046486
[2] https://systemd.io/CREDENTIALS/
[3] https://github.com/canonical/lxd/issues/13631



More information about the ubuntu-devel mailing list