How to fix operation not permitted in Docker

DockerINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 767 views

This error occurs when a process inside a Docker container attempts an operation that is blocked by Linux security features like seccomp, AppArmor, or missing Linux capabilities. The fix involves identifying the blocked syscall and granting appropriate permissions through capabilities, custom seccomp profiles, or SELinux configuration.

Quick fix

Fixes operation not permitted

# 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
  1. Identify the blocked operation
  2. Test if seccomp is the cause
  3. Add required Linux capabilities
  4. Fix SELinux volume mount issues
docker — error
# 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
operation not permitted

What this error means

The "operation not permitted" error (EPERM) in Docker indicates that a process inside your container tried to perform an action that the Linux kernel denied. Unlike "permission denied" (EACCES) which relates to file ownership and permissions, EPERM means the operation itself is not allowed for security reasons. Docker applies multiple layers of security restrictions to containers by default: 1. **Seccomp (Secure Computing Mode)**: Docker's default seccomp profile blocks approximately 44 of the 300+ Linux system calls. This prevents containers from performing potentially dangerous operations like loading kernel modules or rebooting the system. 2. **Linux Capabilities**: Docker drops most Linux capabilities from containers, keeping only a minimal set needed for normal operation. Operations like changing network settings, binding to privileged ports, or creating device nodes require specific capabilities. 3. **AppArmor/SELinux**: On systems with mandatory access control, additional restrictions may apply to container processes and file access. When any of these security layers blocks an operation, the kernel returns EPERM, which applications typically report as "operation not permitted."

Typical symptoms

  • Error messages containing 'Operation not permitted' or 'EPERM'
  • chmod or chown commands failing inside the container
  • Network configuration commands (ifconfig, ip) failing
  • Unable to mount filesystems inside the container
  • Cannot create device nodes with mknod
  • Database or application startup failures related to system calls
  • strace showing EPERM errors on specific syscalls
  • Errors when running containers on macOS Docker Desktop with certain volume mounts

Common causes

  1. Docker's default seccomp profile blocking a required system call
  2. Missing Linux capabilities needed for the operation (e.g., NET_ADMIN, SYS_ADMIN)
  3. SELinux or AppArmor policies restricting access to mounted volumes
  4. NFS volume mounts with root_squash enabled
  5. macOS file system permission restrictions on Docker Desktop
  6. Read-only file system or volume mounts
  7. Container user lacks required permissions despite running as root
  8. Outdated Docker or libseccomp not recognizing newer syscalls

How to fix "operation not permitted"

1Identify the blocked operation

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

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

bash
docker run --rm --cap-add SYS_PTRACE your-image strace your-command 2>&1 | grep EPERM
2Test if seccomp is the cause

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

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

bash
# 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.

3Add required Linux capabilities

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

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

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

4Fix SELinux volume mount issues

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

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

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

To check if SELinux is causing issues:

bash
# Check SELinux status
getenforce

# Temporarily set to permissive (for testing only)
sudo setenforce 0
5Handle NFS volume permission issues

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:

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

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

Option 3: Use named volumes

Named volumes handle permissions better than bind mounts:

bash
docker volume create mydata
docker run -v mydata:/data your-image
6Fix macOS Docker Desktop permissions

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:

dockerfile
# 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.

7Use privileged mode as a last resort

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

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

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

8Update Docker and libseccomp

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

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

bash
sudo systemctl restart docker

Advanced notes

Creating a custom seccomp profile: Instead of disabling seccomp entirely, create a profile that allows only the syscalls you need:

json
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["clone", "clone3"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Use it with: docker run --security-opt seccomp=/path/to/profile.json your-image

Debugging seccomp blocks: Use the audit log to see blocked syscalls:

bash
# Enable audit logging
sudo auditctl -a always,exit -F arch=b64 -S all -k docker_seccomp

# Run the container
docker run your-image your-command

# Check audit log
sudo ausearch -k docker_seccomp | grep SECCOMP

Understanding capability inheritance: Capabilities can be inherited, permitted, or effective. Docker primarily deals with the "effective" set. Some applications may need capabilities in specific sets:

bash
# Check capabilities inside container
docker run --rm --cap-add SYS_ADMIN your-image capsh --print

Rootless Docker considerations: In rootless Docker, even with --privileged, some operations remain restricted because the Docker daemon itself runs without root privileges. Use --userns=host cautiously if needed:

bash
dockerd-rootless-setuptool.sh install
docker context use rootless

Kubernetes SecurityContext: When migrating to Kubernetes, use securityContext to manage capabilities:

yaml
securityContext:
  capabilities:
    add: ["NET_ADMIN", "SYS_TIME"]
    drop: ["ALL"]

AppArmor profiles: On Ubuntu and Debian systems, Docker applies AppArmor profiles. To debug:

bash
# Check if AppArmor is blocking
sudo aa-status
dmesg | grep apparmor

# Run without AppArmor (testing only)
docker run --security-opt apparmor=unconfined your-image

Frequently asked questions

What does "operation not permitted" mean?
The "operation not permitted" error (EPERM) in Docker indicates that a process inside your container tried to perform an action that the Linux kernel denied. Unlike "permission denied" (EACCES) which relates to file ownership and permissions, EPERM means the operation itself is not allowed for security reasons. Docker applies multiple layers of security restrictions to containers by default: 1.
How do I fix "operation not permitted"?
This error occurs when a process inside a Docker container attempts an operation that is blocked by Linux security features like seccomp, AppArmor, or missing Linux capabilities. The fix involves identifying the blocked syscall and granting appropriate permissions through capabilities, custom seccomp profiles, or SELinux configuration.
What causes "operation not permitted"?
Docker's default seccomp profile blocking a required system call Missing Linux capabilities needed for the operation (e.g., NET_ADMIN, SYS_ADMIN) SELinux or AppArmor policies restricting access to mounted volumes
Is the "operation not permitted" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading