How to Fix Docker “OCI runtime create failed” Error [2026 Latest Guide]

Are you getting the “Error response from daemon: OCI runtime create failed” message when trying to start a Docker container? This article provides a comprehensive, up-to-date guide for 2026 on the causes and specific solutions for this error. Whether you’re a beginner or an advanced user, this step-by-step guide will help you resolve the issue.

What Is This Error? Symptoms You’ll Experience
Causes of This Error
Solution 1: Reading Error Messages and Fixing Executable Issues (Recommended)
Solution 2: Fixing Permissions and Security Policies
Solution 3: Upgrading Docker/runc and Fixing cgroup Settings (Advanced)
How to Prevent This Error
Summary
References

What Is This Error? Symptoms You’ll Experience

The “OCI runtime create failed” error indicates that Docker’s low-level container runtime, runc, was unable to start the container process. OCI (Open Container Initiative) is an industry body that defines container standards, and Docker uses an OCI-compliant runtime to manage containers.

When this error occurs, your terminal will display messages like:

docker: Error response from daemon: OCI runtime create failed:
container_linux.go:380: starting container process caused: exec: "python":
executable file not found in $PATH: unknown.

Or:

Error response from daemon: failed to create shim: OCI runtime create failed:
runc create failed: unable to start container process: error during container init:
error mounting "proc" to rootfs at "/proc": permission denied

When this error occurs, your container will not start at all. The docker run command returns an error immediately, making it impossible to access any application inside the container. This error can occur not only in development environments but also in production CI/CD pipelines (CircleCI, GitHub Actions, etc.) and Kubernetes clusters, blocking deployments entirely.

What makes this error particularly frustrating is that the error message is long and complex, making it hard to identify the root cause at first glance. However, the key clue is hidden in the part after “caused:” in the error message. This article explains how to read these clues and provides solutions for each pattern.

Causes of This Error

The “OCI runtime create failed” error has five main causes. Understanding each pattern will help you quickly identify the issue from the error message.

Cause 1: Executable File Not Found (executable file not found in $PATH)

This is one of the most common causes. It occurs when the executable specified in the Dockerfile’s ENTRYPOINT or CMD does not exist in the container image’s $PATH. Specific cases include:

Typos in the command name (e.g., writing pytohn instead of python)
The base image doesn’t include the required command (e.g., bash is not included in alpine images)
Forgetting to copy binaries to the final image in multi-stage builds
Incorrect WORKDIR setting preventing script path resolution

Cause 2: Permission Issues (permission denied)

This occurs when the container startup process lacks the necessary access permissions to files or directories. Common cases include:

The entrypoint script doesn’t have execute permissions (chmod +x)
SELinux or AppArmor on the host machine is blocking container file access
Improper labeling of bind-mounted volumes
Corrupted file ownership under /var/lib/docker

Cause 3: Outdated Docker or runc Versions

Older versions of Docker Engine, containerd, or runc can cause compatibility issues with newer kernel features. In particular, Docker versions below 25 have been reported to cause problems on recent Linux distributions. Compatibility can also break after host OS upgrades (e.g., Proxmox VE 8.1 to 8.2).

Cause 4: cgroup v2 Compatibility Issues

Recent Linux distributions (Ubuntu 22.04+, Fedora 31+, etc.) have cgroup v2 enabled by default. Older versions of Docker or runc that don’t support cgroup v2 will produce errors like:

OCI runtime create failed: runc create failed: unable to start container process:
error during container init: error setting cgroup config for procHooks process

cgroup v2 requires kernel 4.15 or higher (5.2+ recommended).

Cause 5: Disk Space Exhaustion and Resource Conflicts

When Docker images and containers exhaust available disk space, this error appears with a no space left on device message. Conflicts with ports or directories already in use can also cause this error.

Solution 1: Reading Error Messages and Fixing Executable Issues (Recommended)

The most important and effective approach is to accurately read and interpret the error message. For this error, the specific failure reason is stated after caused:.

Step 1: Analyze the Error Message

First, carefully examine the error message. Here’s the typical structure:

Error response from daemon: OCI runtime create failed:
container_linux.go:380: starting container process caused:
exec: "python": executable file not found in $PATH: unknown

In this case, after caused:, it says exec: "python": executable file not found in $PATH. This means the “python” command was not found in the container’s PATH.

Step 2: Check and Fix the Dockerfile

If the error is related to executable files, check your Dockerfile for the following:

# Bad example: alpine image doesn't include python
FROM alpine:latest
CMD ["python", "app.py"]

# Good example: use the official Python image
FROM python:3.12-slim
COPY app.py /app/
WORKDIR /app
CMD ["python", "app.py"]

For bash not found errors (common with Alpine Linux-based images):

# Bad example
RUN /bin/bash -c "echo hello"

# Good example: Alpine includes ash by default
RUN /bin/sh -c "echo hello"

# Or install bash
RUN apk add --no-cache bash

Step 3: Verify Files Inside the Container

You can launch the image interactively to verify file existence:

# Enter the container with a specified shell
docker run --rm -it --entrypoint /bin/sh myimage:latest

# Check commands in PATH
which python
echo $PATH
ls -la /app/

Important Notes

If using multi-stage builds, verify that all required binaries are copied to the final stage
If both ENTRYPOINT and CMD are set, check how they combine (exec form vs shell form)
Verify that COPY instructions correctly copy files and that .dockerignore isn’t excluding them

Solution 2: Fixing Permissions and Security Policies

If the error message contains “permission denied”, the issue is related to permissions or security policies.

Grant Execute Permissions to the Entrypoint Script

# Grant execute permissions locally
chmod +x entrypoint.sh

# Grant permissions in the Dockerfile
COPY entrypoint.sh /app/
RUN chmod +x /app/entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]

Handling SELinux Environments

In SELinux-enabled environments (RHEL, CentOS, Fedora, etc.), policies may block container access to host files.

# Check SELinux status
sestatus

# Check SELinux denial logs
sudo ausearch -m avc -ts recent

# Method 1: Add :z or :Z suffix to volume mounts (recommended)
docker run -v /host/data:/container/data:z myapp:latest

# Method 2: Disable SELinux labels for debugging (not recommended for production)
docker run --security-opt label=disable myapp:latest

The :z suffix makes the volume shareable across multiple containers, while :Z labels it exclusively for that container. Always use :z or :Z in production and avoid label=disable.

Handling AppArmor Environments

Similar issues can occur with AppArmor on Ubuntu and other systems. Notably, since the containerd.io 1.7.28-2 security patch in November 2025, AppArmor-related errors have increased when running Docker inside nested LXC containers.

# Disable AppArmor profile for debugging (not recommended for production)
docker run --security-opt apparmor=unconfined myapp:latest

# Check AppArmor status
sudo aa-status

Fix File Ownership

# Check /var/lib/docker ownership
ls -la /var/lib/docker/

# Restart the Docker daemon if needed
sudo systemctl restart docker

Solution 3: Upgrading Docker/runc and Fixing cgroup Settings (Advanced)

Version compatibility and kernel configuration issues require deeper-level fixes.

Upgrade Docker Engine

Upgrading to Docker 25 or higher resolves many compatibility issues.

# Check current Docker version
docker version

# For Ubuntu/Debian: upgrade from Docker's official repository
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# For CentOS/RHEL
sudo yum update docker-ce docker-ce-cli containerd.io

Upgrade runc Separately

You can also upgrade runc independently:

# Check runc version
runc --version

# Install the latest runc from GitHub releases
wget https://github.com/opencontainers/runc/releases/download/v1.2.5/runc.amd64
sudo install -m 755 runc.amd64 /usr/local/sbin/runc

Address cgroup v2 Compatibility

If you’re experiencing cgroup v2-related errors:

# Check current cgroup version
stat -fc %T /sys/fs/cgroup/
# "cgroup2fs" means v2 is enabled

# Check kernel version (5.2+ recommended)
uname -r

Method A: Modify Docker daemon configuration

# Edit /etc/docker/daemon.json
sudo tee /etc/docker/daemon.json <<EOF
{
  "default-cgroupns-mode": "host",
  "exec-opts": ["native.cgroupdriver=systemd"]
}
EOF

# Restart Docker
sudo systemctl daemon-reload
sudo systemctl restart docker

Method B: Fall back to cgroup v1 (not recommended but effective in emergencies)

Add the following to GRUB boot parameters to force cgroup v1:

# Edit /etc/default/grub
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

# Update GRUB and reboot
sudo update-grub
sudo reboot

Check and Free Disk Space

# Check disk space used by Docker
docker system df

# Remove all unused images, containers, and volumes
docker system prune -a --volumes

# Remove dangling images
docker image prune

Check systemd Service Configuration

In some environments, Docker’s systemd unit file configuration can cause issues:

# Check Docker service unit file
sudo systemctl cat docker.service

# If MountFlags=slave is set, remove it
sudo systemctl edit docker.service
# [Service]
# MountFlags=

# Apply changes
sudo systemctl daemon-reload
sudo systemctl restart docker

How to Prevent This Error

Follow these best practices to prevent the “OCI runtime create failed” error.

1. Follow Dockerfile Best Practices

Use official images as your base
In multi-stage builds, verify that the final stage contains all necessary files
Understand and properly use the difference between ENTRYPOINT and CMD
Properly configure the .dockerignore file

2. Thoroughly Test Locally

# Test that the built image starts correctly
docker build -t myapp:test .
docker run --rm myapp:test

3. Keep Your Docker Environment Updated

Regularly update Docker Engine, containerd, and runc. Apply minor updates containing security patches promptly.

4. Monitor Disk Space Regularly

# Periodically check disk usage
docker system df
# Regular cleanup of unused resources
docker system prune -f --filter "until=168h"

5. Pin Docker Versions in CI/CD Pipelines

When using Docker in CI/CD, pin the Docker version to prevent unexpected compatibility issues.

Summary

Docker’s “OCI runtime create failed” error may look complex, but by carefully reading the part after caused: in the error message, identifying the root cause is relatively straightforward.

Key takeaways:

Executable not found → Check the ENTRYPOINT/CMD in your Dockerfile and specify the correct path and command
Permission errors → Check script execute permissions and SELinux/AppArmor settings
Version compatibility issues → Upgrade Docker, runc, and the kernel to the latest version
cgroup-related issues → Adjust cgroup settings in daemon.json
Disk space issues → Clean up unnecessary resources with docker system prune

If the methods in this article don’t resolve your issue, try:

Post a question on Docker Community Forums (forums.docker.com)
Search for issues on the moby/moby GitHub repository
Ask on Stack Overflow with the output of docker info and docker version

Copying the full error message and searching for it is the most efficient first step toward resolution.