I've made a new installation of Debian 11. Regarding LXC, I copied the working setup of my Debian 10 computer. I use a separate user, lxcuser which I su to, to lxc-start.

The configuration, ~/.config/lxc/default.conf

lxc.idmap = u 0 165536 65536
lxc.idmap = g 0 165536 65536
lxc.apparmor.profile = unconfined
lxc.mount.auto = proc:mixed sys:ro cgroup:mixed
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.net.0.hwaddr = 00:FF:xx:xx:xx:xx
#lxc.include = /etc/lxc/default.conf

File system permissions are set using ACLs, as I did on my previous setup.


LXC version 4.0.6
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-5.10.0-7-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled

--- Control groups ---
Cgroups: enabled

Cgroup v1 mount points:

Cgroup v2 mount points:

Cgroup v1 systemd controller: missing
Cgroup v1 freezer controller: missing
Cgroup namespace: required
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled, not loaded
Macvlan: enabled, not loaded
Vlan: enabled, not loaded
Bridges: enabled, loaded
Advanced netfilter: enabled, loaded
CONFIG_IP6_NF_TARGET_MASQUERADE: enabled, not loaded
FUSE (for use with lxcfs): enabled, loaded

--- Checkpoint/Restore ---
checkpoint restore: enabled
File capabilities:

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

After running with debugging option, I think I've pinned down the error on these lines:

DEBUG    cgfsng - cgroups/cgfsng.c:cgfsng_monitor_create:1355 - Failed to create cgroup "(null)"
WARN     cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - Permission denied - Failed to create directory "/sys/fs/cgroup/user.slice/user-1000.slice/session-1.scope/lxc.monitor.arch"

Changing permissions on /sys/fs/cgroup/user.slice/user-1000.slice/session-1.scope directory has no effect; using sudo cannot write there either.

I believe the issue has arisen due to cgroupv2 which is enabled by default on Debian 11. I tried various ways I found on the net as workabouts, nothing works so far.

Any ideas? Either to make unprivileged LXC work with cgroupv2 or the proper way to disable cgroupv2 and enable cgroupv1 on Debian 11 (or imitate Debian 10's cgroup setup). Other solutions welcomed of course!

Some links:
Same issue, unaswered
My blog on how I setup unprivileged LXC on Debian 10, copied the setup

Update: adding systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false" to kernel parametres helped to start containers. But I still get this error from inside the container:

Arch Linux:

Welcome to Arch Linux!

Failed to create /init.scope control group: Permission denied
Failed to allocate manager object: Permission denied
[!!!!!!] Failed to allocate manager object.
Exiting PID 1...

Centos 8:

Welcome to CentOS Linux 8!

Failed to read AF_UNIX datagram queue length, ignoring: No such file or directory
Failed to install release agent, ignoring: No such file or directory
Failed to create /init.scope control group: Permission denied
Failed to allocate manager object: Permission denied
[!!!!!!] Failed to allocate manager object, freezing.
Freezing execution.

1 Answer 1


The very last version of Debian bullseye LXC package (1:4.0.6-2 from Fri, 11 Jun 2021) somewhat lately warns about changes in starting unprivileged containers in Debian 11 using cgroup v2 and LXC 4.x:

lxc (1:4.0.6-2) unstable; urgency=medium

  • A new way of handling unprivileged containers starting and attachment has
    been made available through the lxc-unpriv-start and lxc-unpriv-attach
    commands. See /usr/share/doc/lxc/README.Debian.gz for more details.

-- Pierre-Elliott Bécue [email protected] Fri, 11 Jun 2021 15:12:15 +0200

First parts in the README appear to have already been addressed by OP. The relevant part for OP's issue is at 7) Starting containers:

  1. Starting containers

Under the unified groups hierarchy (default in systemd starting with Debian 11/bullseye), a non-root user needs lxc-start to have some additional privileges to start container as a non-root user. The easiest way to do that is via systemd. You can either start the container via a user defined service that sets Delegate=true property, or do it explicitly with system-run:

$ systemd-run --scope --quiet --user --property=Delegate=yes \
  lxc-start -n mycontainer

or, lastly, you can use the helper script Debian made available: lxc-unpriv-start. It'll care about using the systemd-run command properly and also to make sure the required environment variables are set properly.

The part "3) Permissions checking" is also worth mentioning (with the right value(s) to adapt):

$ setfacl --modify user:100000:x . .local .local/share

Examples with systemd or with Debian's wrapper:

$ lxc-create -n busybox-amd64 -t busybox

$ lxc-start -n busybox-amd64
lxc-start: busybox-amd64: lxccontainer.c: wait_on_daemonized_start: 859 Received container state "ABORTING" instead of "RUNNING"
lxc-start: busybox-amd64: tools/lxc_start.c: main: 308 The container failed to start
lxc-start: busybox-amd64: tools/lxc_start.c: main: 311 To get more details, run the container in foreground mode
lxc-start: busybox-amd64: tools/lxc_start.c: main: 313 Additional information can be obtained by setting the --logfile and --logpriority options

$ systemd-run --scope --quiet --user --property=Delegate=yes lxc-start -n busybox-amd64
$ lxc-ls --active
$ lxc-stop -n busybox-amd64

$ lxc-unpriv-start -n busybox-amd64
Running scope as unit: run-r1c8a4b4fd0294f688f9f63069414fbf0.scope
$ lxc-ls --active

This information was previously just buried in a few bug reports and places a bit difficult to put together:


Of course this successfully starts real OSes (Debian, CentOS ...) the same.

As a side note and unrelated to this Q/A, today (2021-06-26) using the download template, it appears hkp://pool.sks-keyservers.net is off service. To create a template, I had to do first this to override the default keyserver URL in /usr/share/lxc/templates/lxc-download:

$ export DOWNLOAD_KEYSERVER=hkp://keys.openpgp.org
$ lxc-create -n centos8-amd64 -t download -- --d centos -r 8 -a amd64
You just created a Centos 8 x86_64 (20210626_07:08) container.
  • 2
    Great answer, the unprivileged containers work on Debian 11! I used lxc-unpriv-start -n Name but I got a very detailed error message, pointing me to run sudo loginctl enable-linger lxcuser first. Apparently this is needed because I don't log in as lxcuser, I su to it.
    – Krackout
    Jun 26, 2021 at 20:11
  • Regarding setfacl --modify user:100000:x . .local .local/share: 100000 must be adapted to the actual "numerical subordinate user ID" of the lxc user, e.g. for what is asked in the question (165536): setfacl --modify user:165536:x /home/lxcuser /home/lxcuser/.local /home/lxcuser/.local/share ... or automated: setfacl --modify user:$(grep lxcuser /etc/subuid | cut -d : -f 2):x $(eval echo ~lxcuser) $(eval echo ~lxcuser)/.local $(eval echo ~lxcuser)/.local/share
    – Abdull
    Oct 28, 2022 at 16:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .