Docker inside Linux Containers fails — cgroup delegation not working (TrueNAS 26 Beta)

Apps and Virtualization
1

Summary

Running Docker inside a Linux container (LXC) fails because the cgroup filesystem inside the container is owned by nobody:nogroup, making it impossible for Docker (or any container runtime) to create cgroup scopes. Setting “Capabilities Policy” to “Allow All” does not fix this. Rootless Docker also fails because unprivileged user namespace creation is blocked.

System

  • 26.0.0-BETA.1

  • Container image: ubuntu:noble:amd64:default

What I’m trying to do

Run Docker inside a Linux container to have a proper userspace for managing a Docker Compose stack. This is a well-established pattern on other platforms (Proxmox, standalone Incus, etc.) and requires two things from the host:

  1. Cgroup delegation — the container needs write access to its own cgroup subtree so Docker can create scopes for each container it starts.

  2. Nesting — the container needs permission to create namespaces/cgroups (equivalent to security.nesting=true in Incus).

The error

$ docker run hello-world
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: unable to apply cgroup configuration: mkdir /sys/fs/cgroup/system.slice/docker-<id>.scope: permission denied

Root cause

The cgroup filesystem inside the container is mounted read-write, and systemd is running as the init system with cgroup control. However, all cgroup files and directories are owned by nobody:nogroup (UID/GID 65534):

$ stat /sys/fs/cgroup/system.slice/
Access: (0755/drwxr-xr-x)  Uid: (65534/  nobody)   Gid: (65534/ nogroup)

This means the container’s root user (UID 0) does not have write permission to create new directories under system.slice. On the host, the same cgroup subtree is owned by root:root — but due to the container’s UID mapping, host root doesn’t correspond to container root.

Docker’s cgroup driver is correctly set to systemd, and cgroup v2 is in use:

$ docker info | grep -i cgroup
 Cgroup Driver: systemd
 Cgroup Version: 2

The container’s init process sits under a properly scoped cgroup:

$ cat /proc/1/cgroup
0::/machine.slice/machine-lxc\x2d62831\x2d91b03bce\x2dbdb6\x2d432a\x2d97d7\x2db1df1a8f6814.scope/libvirt/init.scope

What I’ve tried

  • Capabilities Policy → “Allow All”: Same error. Capabilities alone don’t fix the cgroup ownership mismatch.

  • Rootless Docker: Fails with newuidmap: write to uid_map failed: Operation not permitted — the container doesn’t allow creating nested user namespaces either.

Expected behavior

The container’s cgroup subtree should be owned by the container’s root UID (either through proper delegation or identity-mapped UID 0), allowing systemd and Docker to manage cgroups normally. This is how Proxmox LXC containers and standalone Incus with security.nesting=true handle it.

Request

Please add proper cgroup delegation for Linux containers so that nested container runtimes (Docker, Podman, etc.) can function. This is one of the most common use cases for system containers and currently the only blocker — everything else (networking, storage, systemd) works well.

2

Have you used Report a Bug at the upper, top, right of the forums and created a JIRA ticket? If so, please link or post the ticket number. This may fall under a bug or it may require it to be a Feature Requests (Feature Request). Just trying to rule out where it belongs with Bug first, FR, if that fails.

3

Can you try following the instructions here to create a privileged container and see if that works?

2 Likes