How to Fix Docker “OCI Runtime Create Failed” Error [2026 Latest Guide]

Have you ever encountered the “Error response from daemon: OCI runtime create failed” error when trying to start a Docker container? This error indicates that Docker’s low-level container runtime (runc) failed to start the container. In this article, we’ll thoroughly explain the causes and specific solutions for this error based on the latest information from 2026.

What is This Error? Symptoms You May Experience
Causes of This Error
Solution 1: Check Executables and Paths (Recommended)
Solution 2: Addressing SELinux/AppArmor Issues
Solution 3: Upgrading Docker/runc and Configuration Changes (Advanced)
How to Prevent This Error
Summary
References

What is This Error? Symptoms You May Experience

The “OCI runtime create failed” error occurs when Docker attempts to create and start a container using an OCI (Open Container Initiative) compliant runtime (typically runc). OCI is an organization that defines industry standards for container formats and runtimes, and Docker uses runc, which complies with these standards, to manage containers.

When this error occurs, you may experience the following symptoms:

Containers won’t start with the docker run command
Services fail to start with docker-compose up
Container logs display the “OCI runtime create failed” message
Error messages like “runc create failed: unable to start container process” appear

The error message format typically looks like this:

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

This error can occur in any Docker environment, including development environments, CI/CD pipelines, and production environments, significantly impacting container-based application development and deployment.

Causes of This Error

There are multiple potential causes for the OCI runtime create failed error. The key hint is contained in the part after “caused:” in the error message, so it’s important to check the entire error message first.

Cause 1: Executable Not Found

One of the most common causes is that the specified executable or command doesn’t exist within the container. This error occurs when the command specified in the Dockerfile’s ENTRYPOINT or CMD doesn’t exist in the container image.

For example, if you try to run the python command on a base image that doesn’t have Python installed, you’ll see the following error:

exec: "python": executable file not found in $PATH

This frequently occurs when using lightweight images like Alpine Linux.

Cause 2: SELinux/AppArmor Access Control

This error can also occur when security modules like SELinux (Security-Enhanced Linux) or AppArmor block container processes or mount operations. This is particularly problematic in the following situations:

When mounting host directories as volumes
When accessing specific device files
When running containers that require privileged operations

In SELinux-enabled environments, you may see error messages like:

write /proc/self/attr/keycreate: permission denied

Cause 3: Entrypoint Script Issues

Errors can also occur when there are problems with script files like entrypoint.sh specified in the Dockerfile. Main causes include:

File not copied to the image
Incorrect file path
Execute permission not granted
Line endings (CRLF) from scripts created on Windows not recognized on Linux

Cause 4: Docker or runc Version Issues

This error can occur when Docker or runc versions are incompatible with the host OS kernel. Issues have been particularly reported after upgrades in Proxmox VE and other virtualization environments. Many cases are resolved by upgrading to Docker 25 or higher.

Cause 5: cgroup Configuration Issues

Errors also occur when the container’s cgroup (Control Groups) configuration is incompatible with the host system. This issue is frequently reported, especially during the transition period from cgroupsv1 to cgroupsv2.

Solution 1: Check Executables and Paths (Recommended)

The most effective solution to try first is to verify the executables and paths within the container.

Step 1: Check Image Contents

First, verify that the necessary commands exist in the problematic image:

# Check the filesystem in the image
docker run --rm --entrypoint ls myapp:latest /usr/bin/

# Check if a specific command exists
docker run --rm --entrypoint which myapp:latest python

Step 2: Modify the Dockerfile

If the executable doesn’t exist, modify the Dockerfile to install the necessary packages:

# For Alpine Linux
FROM alpine:latest
RUN apk add --no-cache python3 py3-pip

# For Debian/Ubuntu
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y python3 python3-pip

Step 3: Verify ENTRYPOINT and CMD

Check that ENTRYPOINT and CMD are correctly configured in the Dockerfile:

# Correct example
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["python3", "app.py"]

# Using absolute paths is recommended
ENTRYPOINT ["/usr/local/bin/python3"]

Important Notes

When using shell scripts, always grant execute permissions: RUN chmod +x /app/entrypoint.sh
For scripts created on Windows, convert line endings using the dos2unix command or handle it within the Dockerfile

Solution 2: Addressing SELinux/AppArmor Issues

Here’s how to address errors caused by SELinux or AppArmor.

Check SELinux Status

# Check SELinux status
sestatus

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

Label Configuration for Volume Mounts

When mounting volumes in SELinux environments, set appropriate labels:

# :z option (for shared volumes)
docker run -v /host/path:/container/path:z myapp:latest

# :Z option (for private volumes)
docker run -v /host/path:/container/path:Z myapp:latest

Persistent Label Configuration

For frequently used directories, you can set persistent SELinux labels:

# Set SELinux context for containers
chcon -Rt svirt_sandbox_file_t /path/to/volume

Disable SELinux Labels for Testing

For troubleshooting purposes, you can temporarily disable SELinux labels:

docker run --security-opt label=disable myapp:latest

Important: Permanently disabling SELinux is not recommended in production environments. Configure appropriate policies after fully understanding the security risks.

Solution 3: Upgrading Docker/runc and Configuration Changes (Advanced)

Solutions for version issues or when advanced configuration is needed.

Upgrade Docker

If you’re using an older version of Docker, upgrade to the latest version:

# For Ubuntu/Debian
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

Check and Update runc Version

# Check runc version
runc --version

# Update runc separately if needed
sudo apt-get install runc

Modify systemd Configuration

In some environments, you may need to modify Docker’s systemd configuration:

# Edit Docker service file
sudo systemctl edit docker.service

# Add the following configuration (resolves MountFlags issues)
[Service]
MountFlags=shared

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

Configure cgroup Driver

If there are cgroup driver compatibility issues, modify the Docker daemon configuration:

# Edit /etc/docker/daemon.json
sudo nano /etc/docker/daemon.json

Add the following content:

{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}

After configuration, restart Docker:

sudo systemctl restart docker

How to Prevent This Error

Here are best practices to prevent OCI runtime create failed errors.

Dockerfile Best Practices

Use trusted base images: Use official or verified images and ensure they contain necessary dependencies.
Utilize multi-stage builds: Avoid including unnecessary tools or files in the final image.
Explicitly set execute permissions: Always run chmod +x on script files.
Use absolute paths: Use absolute paths rather than relative paths in ENTRYPOINT and CMD.

Regular Maintenance

Keep Docker and runc up to date: Perform regular updates for security patches and compatibility improvements.
Remove unused images and containers: Run docker system prune regularly to free up disk space.
Monitor logs: Regularly check Docker system logs with journalctl -u docker.

Pre-deployment Testing

Always verify that containers start correctly in local or staging environments before deploying to production. It’s also effective to incorporate container startup tests into your CI/CD pipeline.

Summary

The Docker “OCI runtime create failed” error is a common error indicating that the container runtime couldn’t start the container. Main causes include missing executables, SELinux/AppArmor access control, entrypoint configuration errors, Docker/runc version issues, and cgroup configuration inconsistencies.

When troubleshooting, it’s important to first check the portion after “caused:” in the error message to identify the specific cause. In many cases, the issue can be resolved by modifying the Dockerfile or adding volume mount options.

If the problem persists, try the following steps:

Check more detailed error information with docker logs or journalctl
Search for similar issues on Docker official forums or Stack Overflow
Consider upgrading your Docker version
Verify compatibility between the host OS kernel and Docker

Container technology evolves daily, and many issues are resolved in newer versions. Maintain a stable container environment through regular updates and proper configuration management.