In LXD containers running systemd v259 (currently in
resolute-proposed), any systemd service attempting to use systemd
credentials via ImportCredential= et al will fail with something
similar to:
$ systemctl status systemd-resolved
× systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service;
enabled; preset: enabled)
Active: failed (Result: exit-code) since Mon 2025-12-01 17:55:08
UTC; 2min 30s ago
Duration: 51.860s
Invocation: 91a83903b1b546cb934b1bbc1fdb8d40
TriggeredBy: × systemd-resolved-monitor.socket
× systemd-resolved-varlink.socket
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
https://systemd.io/WRITING_RESOLVER_CLIENTS
Process: 1431 ExecStart=/usr/lib/systemd/systemd-resolved
(code=exited, status=243/CREDENTIALS)
Main PID: 1431 (code=exited, status=243/CREDENTIALS)
Mem peak: 2.2M
CPU: 9ms
This is due to an AppArmor denial, and needs to be addressed in the
LXD AppArmor profiles for containers. There is an upstream bug
tracking this[1].
If this sounds like déjà vu, it is [2].
For workaround in the mean time, you can either:
(1) Configure security.nesting=true on your resolute containers. NOTE:
This is not the approach that LXD will take in the end.
(2) Use systemd drop-ins to disable the use of credential related
settings. For example, to disable these for all services:
$ mkdir -p /etc/systemd/system/service.d/
$ cat > /etc/systemd/system/service.d/disable-credentials.conf << EOF
[Service]
ImportCredential=
LoadCredential=
LoadCredentialEncrypted=
SetCredential=
SetCredentialEncrypted=
EOF
You can of course use more specific drop-ins, if you prefer.
Thanks,
Nick
[1] https://github.com/canonical/lxd/issues/17073
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2024-July/043056.html
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
