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

First, identify which cgroup version your system uses:

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

Verify cgroups are properly mounted:

mount | grep cgroup

Check Docker's cgroup driver:

docker info | grep -i cgroup

You should see output like:

Cgroup Driver: systemd
Cgroup Version: 2

If "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-session

Fedora/RHEL/CentOS:

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:

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

If empty, start a new login session or run:

systemctl --user start dbus

Rootless 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
EOF

Reload systemd and restart:

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

Verify delegation is enabled:

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

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

Install cgroup utilities:

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

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/cgroup

On 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.txt

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

cgroup_enable=memory cgroup_memory=1

For GRUB-based systems:

sudo nano /etc/default/grub

Add to GRUB_CMDLINE_LINUX:

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

Update GRUB and reboot:

sudo update-grub
sudo reboot

Verify memory cgroup is enabled after reboot:

cat /proc/cgroups | grep memory

When 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:dind

Initialize 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_control

Alternative: Use host cgroup namespace:

docker run --cgroupns=host your-image

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

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 docker

Alternative: 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 docker

Sometimes a simple restart resolves transient cgroup issues:

Linux (systemd):

sudo systemctl restart docker

Linux (service):

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:

Restart-Service docker

After restarting, test with a simple container:

docker run --rm hello-world

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