How to Fix Docker OCI Runtime Create Failed: Permission Denied
Quick Fix Summary
TL;DRRun `sudo chmod 666 /var/run/docker.sock` to grant immediate container execution permissions.
The Docker daemon cannot create a new container due to insufficient permissions on critical runtime resources. This blocks container execution entirely, halting deployments and services.
Diagnosis & Causes
Recovery Steps
Step 1: Verify and Fix Docker Socket Permissions
The Docker daemon communicates via a Unix socket. Incorrect permissions here prevent container creation.
# Check current socket permissions
ls -la /var/run/docker.sock
# Grant read/write to the docker group (safer)
sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock
# OR, for immediate recovery (less secure)
sudo chmod 666 /var/run/docker.sockStep 2: Add Your User to the Docker Group
Ensure your non-root user has the correct group membership to interact with the Docker daemon.
# Add your user to the 'docker' group
sudo usermod -aG docker $USER
# Log out and back in, or run:
newgrp docker
# Verify group membership
groups $USERStep 3: Diagnose and Configure SELinux/AppArmor
Mandatory Access Control (MAC) systems can block container processes. Check audit logs and adjust policies.
# For SELinux (RHEL/CentOS/Fedora)
sudo ausearch -m avc -ts recent | grep docker
# Temporarily set SELinux to permissive for testing
sudo setenforce 0
# If it works, create a custom policy or adjust labels.
# For AppArmor (Ubuntu/Debian)
sudo aa-status | grep docker
sudo apparmor_parser -r /etc/apparmor.d/dockerStep 4: Check Rootless Docker Configuration
If using rootless mode, ensure user namespaces and subuid/subgid mappings are correctly configured.
# Verify rootless Docker is installed and running
docker context ls
docker context use rootless
# Check subuid/subgid mappings for your user
grep $USER /etc/subuid
grep $USER /etc/subgid
# Reconfigure if mappings are missing
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 $USERStep 5: Inspect Container Filesystem Mount Permissions
Volume mounts or container image layers with restrictive ownership can cause permission errors inside the container namespace.
# Run container with debug shell to inspect internal permissions
docker run -it --rm --entrypoint /bin/sh <your_image>
# Inside container, check critical paths:
whoami
ls -la /
ls -la /tmp
ls -la /var/run
# For volume mounts, ensure host directory is accessible
ls -la /path/on/hostStep 6: Restart Docker Daemon and Test
Apply configuration changes and restart the Docker service to clear any runtime state.
# Restart Docker service (systemd)
sudo systemctl restart docker
# OR restart the rootless daemon
systemctl --user restart docker
# Verify daemon is running and test with a simple container
docker run --rm hello-worldArchitect's Pro Tip
"In CI/CD pipelines, this error often surfaces after a host OS upgrade. Always run `docker system info` as part of your post-upgrade validation checklist."
Frequently Asked Questions
Is setting /var/run/docker.sock to 666 (chmod 666) safe for production?
No, it's a temporary recovery fix. It grants write access to all users on the system, creating a security risk. The permanent, secure solution is `chmod 660` and ensuring only the `docker` group has access.
Why does this error happen suddenly on a previously working system?
Common triggers are: a system update that changed default socket permissions, a Docker upgrade that reset the context, or a user being removed from the `docker` group by another admin process.
Can this error be caused by the container image itself?
Indirectly, yes. If the image defines a non-root user (USER directive) that lacks permissions on a mounted volume or a directory the OCI runtime needs (like /proc), it can manifest as a permission denied error at runtime creation.