This error occurs when Docker cannot apply cgroup (control group) configuration during container initialization. It typically happens due to cgroup version mismatches, missing cgroup mounts, D-Bus session issues in rootless mode, or insufficient permissions. The fix depends on your environment and cgroup version.
Fixes OCI runtime create failed: unable to start container process: error during container init: unable to apply cgroup
# Check cgroup version
stat -fc %T /sys/fs/cgroup/
# Returns "cgroup2fs" for v2, "tmpfs" for v1# Check cgroup versionstat -fc %T /sys/fs/cgroup/# Returns "cgroup2fs" for v2, "tmpfs" for v1OCI runtime create failed: unable to start container process: error during container init: unable to apply cgroup
The "unable to apply cgroup" error occurs during the OCI (Open Container Initiative) runtime initialization phase when Docker attempts to set up resource constraints for a new container. Cgroups (control groups) are a Linux kernel feature that Docker relies on to limit and monitor container resources like CPU, memory, and I/O. When you see this error, it means the container runtime (typically runc) failed to configure the cgroup hierarchy for your container. This can happen for several reasons: the system's cgroup filesystem isn't properly mounted, there's a mismatch between cgroup v1 and v2 expectations, rootless Docker lacks proper D-Bus session access, or Docker-in-Docker scenarios have conflicting cgroup configurations. The error message usually includes additional context about which specific cgroup operation failed, such as "mkdir /sys/fs/cgroup/memory/docker/...: read-only file system" or "cannot enter cgroupv2 '/sys/fs/cgroup/docker' with domain controllers -- it is in threaded mode".
First, identify which cgroup version your system uses:
# Check cgroup version
stat -fc %T /sys/fs/cgroup/
# Returns "cgroup2fs" for v2, "tmpfs" for v1Verify cgroups are properly mounted:
mount | grep cgroupCheck Docker's cgroup driver:
docker info | grep -i cgroupYou should see output like:
Cgroup Driver: systemd
Cgroup Version: 2If "Cgroup Driver" shows "none", Docker cannot use cgroups and resource limits won't work.
If you're running rootless Docker, the most common cause is a missing D-Bus user session. Install the required package:
Debian/Ubuntu:
sudo apt-get install -y dbus-user-sessionFedora/RHEL/CentOS:
sudo dnf install -y dbus-daemonAfter installation, you must log out and log back in (or reboot) for the D-Bus session to start properly.
Verify D-Bus is running:
echo $DBUS_SESSION_BUS_ADDRESS
# Should output something like: unix:path=/run/user/1000/busIf empty, start a new login session or run:
systemctl --user start dbusRootless Docker requires cgroup delegation to apply resource limits. Enable it:
# Create or edit the systemd user override
mkdir -p ~/.config/systemd/user/Create a delegate configuration:
sudo mkdir -p /etc/systemd/system/[email protected]/
sudo tee /etc/systemd/system/[email protected]/delegate.conf << EOF
[Service]
Delegate=cpu cpuset io memory pids
EOFReload systemd and restart:
sudo systemctl daemon-reload
systemctl --user daemon-reloadVerify delegation is enabled:
cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllersThis should list available controllers like "cpu memory pids".
If cgroup mounts are missing, create them manually:
For cgroup v1 (legacy):
# Mount the systemd cgroup (often needed for Docker Toolbox/older systems)
sudo mkdir -p /sys/fs/cgroup/systemd
sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemdInstall cgroup utilities:
# Debian/Ubuntu
sudo apt-get install -y cgroup-lite cgroup-tools
# This often auto-mounts the required cgroup hierarchiesFor read-only cgroup filesystem errors:
If you see "read-only file system" errors, you may be in a restricted environment (container, VM, or cloud instance). Check if cgroups are mounted read-only:
mount | grep cgroup | grep -E "ro[,)]"You may need to remount with write permissions (if your environment allows):
sudo mount -o remount,rw /sys/fs/cgroupOn some systems (especially Raspberry Pi), memory cgroup may be disabled by default:
Raspberry Pi (Raspbian/Raspberry Pi OS):
Edit the boot configuration:
sudo nano /boot/cmdline.txt
# or on newer versions:
sudo nano /boot/firmware/cmdline.txtAdd these parameters at the end of the existing line (don't create a new line):
cgroup_enable=memory cgroup_memory=1For GRUB-based systems:
sudo nano /etc/default/grubAdd to GRUB_CMDLINE_LINUX:
GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"Update GRUB and reboot:
sudo update-grub
sudo rebootVerify memory cgroup is enabled after reboot:
cat /proc/cgroups | grep memoryWhen running Docker inside a Docker container, cgroup errors are common. The solution depends on your cgroup version:
For cgroup v2 systems, enable nesting:
# Run the outer container with proper privileges
docker run -d --name dind \
--privileged \
--cgroupns=host \
-v /sys/fs/cgroup:/sys/fs/cgroup:rw \
docker:dindInitialize cgroup controllers for nested containers:
Inside the DinD container, you may need to:
# Move processes from root cgroup to allow subtree_control modifications
mkdir -p /sys/fs/cgroup/init
echo $$ > /sys/fs/cgroup/init/cgroup.procs
# Enable controllers
echo "+cpu +memory +io +pids" > /sys/fs/cgroup/cgroup.subtree_controlAlternative: Use host cgroup namespace:
docker run --cgroupns=host your-imageOr add to daemon.json:
{
"default-cgroupns-mode": "host"
}Ensure Docker's cgroup driver matches your system. Edit /etc/docker/daemon.json:
For systems using systemd (most modern Linux distros):
{
"exec-opts": ["native.cgroupdriver=systemd"]
}For systems using cgroupfs:
{
"exec-opts": ["native.cgroupdriver=cgroupfs"]
}Restart Docker:
sudo systemctl restart dockerImportant notes:
- cgroup v2 systems should use "systemd" driver
- cgroup v1 systems can use either, but "cgroupfs" is default
- Don't mix drivers between Docker and Kubernetes on the same node
Verify the change:
docker info | grep "Cgroup Driver"If the error occurred after a crash or forced shutdown, container metadata may be corrupted:
# Stop Docker
sudo systemctl stop docker
# Remove corrupted container directories (careful!)
# First, list potentially problematic containers
sudo ls -la /var/lib/docker/containers/
# If you identify a corrupted container, remove it
sudo rm -rf /var/lib/docker/containers/<container_id>
# Start Docker
sudo systemctl start dockerAlternative: Full cleanup (destructive)
If multiple containers are affected:
# WARNING: This removes all containers, images, and volumes
docker system prune -a --volumes
# Or restart with a clean slate
sudo systemctl stop docker
sudo rm -rf /var/lib/docker
sudo systemctl start dockerSometimes a simple restart resolves transient cgroup issues:
Linux (systemd):
sudo systemctl restart dockerLinux (service):
sudo service docker restartDocker Desktop (Windows/macOS):
- Right-click the Docker Desktop icon in the system tray
- Select "Restart"
Or via command line on Windows:
Restart-Service dockerAfter restarting, test with a simple container:
docker run --rm hello-worldIf that works but containers with resource limits fail, the issue is specifically with cgroup resource controllers.
Understanding cgroup v1 vs v2:
Cgroup v1 (legacy) uses multiple hierarchies - separate trees for memory, cpu, blkio, etc. Cgroup v2 (unified) uses a single hierarchy. Docker supports both, but behavior differs:
- cgroup v1: Default in older kernels, being deprecated
- cgroup v2: Default in newer systems (Ubuntu 21.10+, Fedora 31+, Debian 11+)
Check your version:
grep cgroup /proc/filesystems
# "cgroup" = v1, "cgroup2" = v2Cgroup deprecation warning: Docker shows "cgroup v1 is deprecated" because support will be removed after May 2029. Plan to migrate to cgroup v2.
Rootless Docker limitations:
With rootless Docker on cgroup v1, resource limiting is NOT supported. You'll see "none" as the Cgroup Driver. This is expected behavior - upgrade to cgroup v2 for full rootless support.
WSL considerations:
WSL1 doesn't support cgroups at all. WSL2 has limited cgroup support. If you see cgroup errors in WSL:
# Check WSL version
wsl.exe -l -v
# WSL2 should work, WSL1 won'tFor WSL2, ensure you're using Docker Desktop with the WSL2 backend, not Docker inside the WSL distro directly.
Kubernetes and cgroup driver:
If running Kubernetes, ensure kubelet and Docker use the same cgroup driver:
# /var/lib/kubelet/config.yaml
cgroupDriver: systemdMismatch causes node instability and pod failures.
Debugging cgroup issues:
# View cgroup hierarchy
ls -la /sys/fs/cgroup/
# Check container's cgroup
cat /proc/self/cgroup
# For a running container
docker inspect --format '{{.HostConfig.CgroupParent}}' <container>
# View cgroup controllers
cat /sys/fs/cgroup/cgroup.controllers
# Check systemd cgroup status
systemctl statusUsing cgroupns mode:
Docker supports cgroup namespaces (cgroupns). Setting it to "host" can resolve some isolation issues:
docker run --cgroupns=host your-imageThis makes the container see the host's cgroup hierarchy, which can help with Docker-in-Docker but reduces isolation.