How to fix operation not permitted in Docker

First, determine exactly which operation is being blocked. Check the full error message and context:

# Run the failing command with verbose output
docker run --rm your-image sh -c "your-command 2>&1"

# Or attach to a running container to debug
docker exec -it container_name sh

Common patterns:
- chmod/chown failing: Usually capability or volume mount issue
- Network commands failing: Missing NET_ADMIN or NET_RAW capability
- mknod failing: Missing MKNOD capability or seccomp block
- mount failing: Missing SYS_ADMIN capability

For detailed syscall information, use strace (if available in your container):

docker run --rm --cap-add SYS_PTRACE your-image strace your-command 2>&1 | grep EPERM

Temporarily disable seccomp to verify it's the source of the problem:

docker run --security-opt seccomp=unconfined --rm your-image your-command

Important: Only use seccomp=unconfined for testing. If this solves the issue, your next step is to create a custom seccomp profile that allows only the specific syscalls needed.

To identify which syscall is blocked, you can use:

# Generate a log of blocked syscalls
docker run --security-opt seccomp=unconfined \
  --security-opt apparmor=unconfined \
  --cap-add ALL \
  your-image your-command

If the command works with seccomp disabled, the default profile is blocking a required syscall.

Docker drops most capabilities by default. Add specific capabilities your application needs:

# Add a single capability
docker run --cap-add NET_ADMIN your-image

# Add multiple capabilities
docker run --cap-add NET_ADMIN --cap-add NET_RAW your-image

# Common capabilities for specific operations:
# - NET_ADMIN: Network configuration (ifconfig, ip, iptables)
# - NET_RAW: Raw sockets (ping, some network tools)
# - SYS_ADMIN: Mount, some cgroup operations (use sparingly)
# - MKNOD: Create device nodes
# - SYS_PTRACE: Debug/trace processes (strace, gdb)
# - IPC_LOCK: Lock memory (databases, real-time apps)

For Docker Compose:

services:
  myapp:
    image: your-image
    cap_add:
      - NET_ADMIN
      - NET_RAW

Security note: Only add capabilities that are strictly required. Each capability increases the attack surface of your container.

On systems with SELinux (RHEL, CentOS, Fedora), you may need to relabel volumes:

# Add :z for shared volumes (multiple containers)
docker run -v /host/path:/container/path:z your-image

# Add :Z for private volumes (single container)
docker run -v /host/path:/container/path:Z your-image

The :z and :Z options tell Docker to relabel the volume with appropriate SELinux contexts:
- :z - Shared label, allows multiple containers to access
- :Z - Private label, restricts to a single container (more secure)

For read-only mounts with SELinux:

docker run -v /host/path:/container/path:ro,Z your-image

To check if SELinux is causing issues:

# Check SELinux status
getenforce

# Temporarily set to permissive (for testing only)
sudo setenforce 0

NFS mounts with root_squash (the default) map the root user to nobody, causing permission errors:

Option 1: Use matching UID/GID

Run the container as a user that matches the NFS share owner:

# Find the owner UID/GID on the NFS share
ls -ln /nfs/mount/path

# Run container with matching user
docker run --user 1000:1000 -v /nfs/share:/data your-image

Option 2: Configure NFS server

If you control the NFS server, you can use no_root_squash (not recommended for security) or better, anonuid/anongid:

# /etc/exports
/shared/path  *(rw,sync,anonuid=1000,anongid=1000)

Option 3: Use named volumes

Named volumes handle permissions better than bind mounts:

docker volume create mydata
docker run -v mydata:/data your-image

Docker Desktop on macOS (Catalina and later) requires explicit permissions for file access:

Step 1: Grant Docker full disk access
1. Open System Preferences (or System Settings on newer macOS)
2. Go to Privacy & Security > Full Disk Access
3. Click the lock to make changes
4. Add Docker (or Docker Desktop) to the list
5. Toggle it ON
6. Restart Docker Desktop

Step 2: If using specific directories, ensure they're in Docker's file sharing settings:
1. Open Docker Desktop
2. Go to Settings > Resources > File Sharing
3. Add the directories you need to mount
4. Click Apply & Restart

Step 3: For persistent issues, try copying files instead of mounting:

# In your Dockerfile, copy files instead of relying on mounts
COPY ./local-files /app/files

Or use Docker volumes instead of bind mounts for data that needs write access.

If nothing else works and security is not a primary concern (development only), you can run in privileged mode:

docker run --privileged your-image

Warning: Privileged mode disables nearly all security restrictions. The container has:
- Full access to all devices
- Can load kernel modules
- Can modify the host system
- No seccomp restrictions
- All capabilities granted

Never use privileged mode in production. Instead, identify the specific capability or syscall needed and grant only that.

For Docker Compose:

services:
  myapp:
    image: your-image
    privileged: true  # DEVELOPMENT ONLY

If you need privileged mode to work, document which operations require it and work toward a least-privilege solution.

Outdated versions of Docker or libseccomp may not recognize newer system calls, causing false EPERM errors:

# Check current versions
docker version
apt show libseccomp2 2>/dev/null || rpm -q libseccomp

# Update on Ubuntu/Debian
sudo apt update && sudo apt upgrade docker-ce libseccomp2

# Update on RHEL/CentOS
sudo yum update docker-ce libseccomp

# Update on Fedora
sudo dnf update docker-ce libseccomp

This is particularly important when running containers based on newer distributions (like Ubuntu 22.04) on older hosts.

After updating, restart Docker:

sudo systemctl restart docker