How to fix OCI runtime create failed: unable to start container process: error during container init: unable to apply cgroup in Docker

DockerADVANCEDHIGHUpdated Dec 6, 2025· 339 views

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.

Quick fix

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
  1. Check your cgroup version and configuration
  2. Install and configure D-Bus (rootless Docker)
  3. Enable cgroup delegation for rootless Docker
  4. Mount missing cgroup filesystems
docker — error
# Check cgroup version
stat -fc %T /sys/fs/cgroup/
# Returns "cgroup2fs" for v2, "tmpfs" for v1
OCI runtime create failed: unable to start container process: error during container init: unable to apply cgroup

What this error means

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".

Typical symptoms

  • Container fails to start with 'OCI runtime create failed' message
  • Error mentions 'unable to apply cgroup configuration'
  • Container creation works with --privileged but fails without it
  • Docker commands work as root but fail in rootless mode
  • Docker-in-Docker scenarios fail when parent container has resource limits
  • Containers fail after system upgrade or kernel update
  • Error occurs specifically when setting memory, CPU, or other resource limits

Common causes

  1. D-Bus user session not running (common in rootless Docker)
  2. Cgroup v1/v2 version mismatch between Docker and the host system
  3. Cgroup filesystem not properly mounted or mounted read-only
  4. Missing cgroup controllers (memory, cpu, cpuset) not enabled in kernel
  5. Docker-in-Docker with conflicting cgroup configurations
  6. Rootless Docker without proper cgroup delegation
  7. Corrupted container metadata in /var/lib/docker/containers
  8. systemd cgroup driver conflicts with cgroupfs driver
  9. Container running in an environment without cgroup support (some VPS, WSL1)

How to fix "OCI runtime create failed: unable to start container process: error during container init: unable to apply cgroup"

1Check your cgroup version and configuration

First, identify which cgroup version your system uses:

bash
# Check cgroup version
stat -fc %T /sys/fs/cgroup/
# Returns "cgroup2fs" for v2, "tmpfs" for v1

Verify cgroups are properly mounted:

bash
mount | grep cgroup

Check Docker's cgroup driver:

bash
docker info | grep -i cgroup

You should see output like:

bash
Cgroup Driver: systemd
Cgroup Version: 2

If "Cgroup Driver" shows "none", Docker cannot use cgroups and resource limits won't work.

2Install and configure D-Bus (rootless Docker)

If you're running rootless Docker, the most common cause is a missing D-Bus user session. Install the required package:

Debian/Ubuntu:

bash
sudo apt-get install -y dbus-user-session

Fedora/RHEL/CentOS:

bash
sudo dnf install -y dbus-daemon

After installation, you must log out and log back in (or reboot) for the D-Bus session to start properly.

Verify D-Bus is running:

bash
echo $DBUS_SESSION_BUS_ADDRESS
# Should output something like: unix:path=/run/user/1000/bus

If empty, start a new login session or run:

bash
systemctl --user start dbus
3Enable cgroup delegation for rootless Docker

Rootless Docker requires cgroup delegation to apply resource limits. Enable it:

bash
# Create or edit the systemd user override
mkdir -p ~/.config/systemd/user/

Create a delegate configuration:

bash
sudo mkdir -p /etc/systemd/system/user@.service.d/
sudo tee /etc/systemd/system/user@.service.d/delegate.conf << EOF
[Service]
Delegate=cpu cpuset io memory pids
EOF

Reload systemd and restart:

bash
sudo systemctl daemon-reload
systemctl --user daemon-reload

Verify delegation is enabled:

bash
cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers

This should list available controllers like "cpu memory pids".

4Mount missing cgroup filesystems

If cgroup mounts are missing, create them manually:

For cgroup v1 (legacy):

bash
# 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/systemd

Install cgroup utilities:

bash
# Debian/Ubuntu
sudo apt-get install -y cgroup-lite cgroup-tools

# This often auto-mounts the required cgroup hierarchies

For 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:

bash
mount | grep cgroup | grep -E "ro[,)]"

You may need to remount with write permissions (if your environment allows):

bash
sudo mount -o remount,rw /sys/fs/cgroup
5Enable memory cgroup in kernel (Raspberry Pi/embedded)

On some systems (especially Raspberry Pi), memory cgroup may be disabled by default:

Raspberry Pi (Raspbian/Raspberry Pi OS):

Edit the boot configuration:

bash
sudo nano /boot/cmdline.txt
# or on newer versions:
sudo nano /boot/firmware/cmdline.txt

Add these parameters at the end of the existing line (don't create a new line):

bash
cgroup_enable=memory cgroup_memory=1

For GRUB-based systems:

bash
sudo nano /etc/default/grub

Add to GRUB_CMDLINE_LINUX:

bash
GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

Update GRUB and reboot:

bash
sudo update-grub
sudo reboot

Verify memory cgroup is enabled after reboot:

bash
cat /proc/cgroups | grep memory
6Fix Docker-in-Docker cgroup issues

When running Docker inside a Docker container, cgroup errors are common. The solution depends on your cgroup version:

For cgroup v2 systems, enable nesting:

bash
# Run the outer container with proper privileges
docker run -d --name dind \
  --privileged \
  --cgroupns=host \
  -v /sys/fs/cgroup:/sys/fs/cgroup:rw \
  docker:dind

Initialize cgroup controllers for nested containers:

Inside the DinD container, you may need to:

bash
# 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_control

Alternative: Use host cgroup namespace:

bash
docker run --cgroupns=host your-image

Or add to daemon.json:

json
{
  "default-cgroupns-mode": "host"
}
7Configure the cgroup driver correctly

Ensure Docker's cgroup driver matches your system. Edit /etc/docker/daemon.json:

For systems using systemd (most modern Linux distros):

json
{
  "exec-opts": ["native.cgroupdriver=systemd"]
}

For systems using cgroupfs:

json
{
  "exec-opts": ["native.cgroupdriver=cgroupfs"]
}

Restart Docker:

bash
sudo systemctl restart docker

Important 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:

bash
docker info | grep "Cgroup Driver"
8Clean up corrupted container data

If the error occurred after a crash or forced shutdown, container metadata may be corrupted:

bash
# 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 docker

Alternative: Full cleanup (destructive)

If multiple containers are affected:

bash
# 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 docker
9Restart Docker daemon

Sometimes a simple restart resolves transient cgroup issues:

Linux (systemd):

bash
sudo systemctl restart docker

Linux (service):

bash
sudo service docker restart

Docker Desktop (Windows/macOS):
- Right-click the Docker Desktop icon in the system tray
- Select "Restart"

Or via command line on Windows:

powershell
Restart-Service docker

After restarting, test with a simple container:

bash
docker run --rm hello-world

If that works but containers with resource limits fail, the issue is specifically with cgroup resource controllers.

Advanced notes

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:

bash
grep cgroup /proc/filesystems
# "cgroup" = v1, "cgroup2" = v2

Cgroup 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:

bash
# Check WSL version
wsl.exe -l -v

# WSL2 should work, WSL1 won't

For 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:

yaml
# /var/lib/kubelet/config.yaml
cgroupDriver: systemd

Mismatch causes node instability and pod failures.

Debugging cgroup issues:

bash
# 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 status

Using cgroupns mode:

Docker supports cgroup namespaces (cgroupns). Setting it to "host" can resolve some isolation issues:

bash
docker run --cgroupns=host your-image

This makes the container see the host's cgroup hierarchy, which can help with Docker-in-Docker but reduces isolation.

Frequently asked questions

What does "OCI runtime create failed: unable to start container process: error du" mean?
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.
How do I fix "OCI runtime create failed: unable to start container process: error du"?
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.
What causes "OCI runtime create failed: unable to start container process: error du"?
D-Bus user session not running (common in rootless Docker) Cgroup v1/v2 version mismatch between Docker and the host system Cgroup filesystem not properly mounted or mounted read-only
Is the "OCI runtime create failed: unable to start container process: error du" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading