How to fix Error response from daemon: operation not permitted: capability not permitted in Docker

DockerINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 406 views

This error occurs when a Docker container attempts to use a Linux capability that has not been granted. The container is trying to perform a privileged operation (like modifying network interfaces or mounting filesystems) but lacks the required capability. Fix by adding specific capabilities with --cap-add or reviewing your security constraints.

Quick fix

Fixes Error response from daemon: operation not permitted: capability not permitted

# Run with strace to see failing syscalls
docker run --rm -it --cap-add SYS_PTRACE your-image strace -f your-command 2>&1 | grep -i "permission denied\|operation not permitted"
  1. Identify the required capability
  2. Add the specific capability with --cap-add
  3. Verify container capabilities
  4. Address seccomp restrictions if capabilities alone do not work
docker — error
# Run with strace to see failing syscalls
docker run --rm -it --cap-add SYS_PTRACE your-image strace -f your-command 2>&1 | grep -i "permission denied\|operation not permitted"
Error response from daemon: operation not permitted: capability not permitted

What this error means

When Docker runs a container, it operates with a restricted set of Linux capabilities by default. Linux capabilities are a way to break down the monolithic root privileges into smaller, more granular permissions. Instead of giving a process full root access, the kernel can grant specific capabilities like CAP_NET_ADMIN (network administration) or CAP_SYS_ADMIN (system administration). Docker drops most capabilities by default for security reasons. The default set includes only basic capabilities like CHOWN, DAC_OVERRIDE, FSETID, FOWNER, MKNOD, NET_RAW, SETGID, SETUID, SETFCAP, SETPCAP, NET_BIND_SERVICE, SYS_CHROOT, KILL, and AUDIT_WRITE. When your application tries to perform an operation requiring a capability outside this default set, the kernel denies the operation with "capability not permitted." This error commonly appears when: - Running network tools that need to modify interfaces (requires CAP_NET_ADMIN) - Mounting filesystems inside containers (requires CAP_SYS_ADMIN) - Running Docker inside Docker or LXC (nested containerization) - Using applications that require low-level system access - Running security tools or network analyzers

Typical symptoms

  • Container fails with 'operation not permitted: capability not permitted'
  • Network configuration commands (ip, iptables) fail inside the container
  • Mount operations fail within the container
  • Applications that work as root on the host fail inside the container
  • Nested container operations fail (Docker-in-Docker, Docker-in-LXC)
  • Security or monitoring tools cannot access required kernel features
  • Containers that worked in development fail in production with restricted policies

Common causes

  1. Container attempting to use a Linux capability not in Docker's default set
  2. Application requires CAP_NET_ADMIN, CAP_SYS_ADMIN, or other elevated capabilities
  3. Running Docker inside LXC containers without proper capability configuration
  4. Seccomp profile blocking system calls required by the application
  5. AppArmor or SELinux policies restricting container capabilities
  6. Kubernetes or orchestrator-level security policies dropping capabilities
  7. Using rootless Docker mode which has additional capability restrictions
  8. Container image expecting privileged operations that the runtime denies

How to fix "Error response from daemon: operation not permitted: capability not permitted"

1Identify the required capability

First, determine which capability your application needs. Common capabilities and their use cases:

| Capability | Purpose |
|------------|---------|
| CAP_NET_ADMIN | Network interface configuration, iptables, routing |
| CAP_SYS_ADMIN | Mount operations, namespace management, many admin tasks |
| CAP_NET_RAW | Raw socket access, ping, packet capture |
| CAP_SYS_PTRACE | Debugging, strace, process inspection |
| CAP_IPC_LOCK | Memory locking (mlock, mlockall) |
| CAP_SYS_TIME | System clock modification |

Check what your application is trying to do:

bash
# Run with strace to see failing syscalls
docker run --rm -it --cap-add SYS_PTRACE your-image strace -f your-command 2>&1 | grep -i "permission denied\|operation not permitted"

Common operations and their required capabilities:

- ip link, ip addr, iptables -> CAP_NET_ADMIN
- mount, umount -> CAP_SYS_ADMIN
- ping (ICMP) -> CAP_NET_RAW
- strace, gdb -> CAP_SYS_PTRACE

2Add the specific capability with --cap-add

Once you know which capability is needed, add it using the --cap-add flag. Always prefer adding specific capabilities over using --privileged.

Add a single capability:

bash
# For network administration (iptables, ip commands)
docker run --cap-add NET_ADMIN your-image

# For system administration tasks
docker run --cap-add SYS_ADMIN your-image

# For raw network access
docker run --cap-add NET_RAW your-image

Add multiple capabilities:

bash
docker run --cap-add NET_ADMIN --cap-add SYS_ADMIN your-image

Note: Docker uses capability names without the CAP_ prefix. Use NET_ADMIN not CAP_NET_ADMIN.

In Docker Compose:

yaml
version: "3"
services:
  myapp:
    image: your-image
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN
3Verify container capabilities

Confirm which capabilities your container actually has:

Check current capabilities inside the container:

bash
# Run an interactive shell with your capabilities
docker run --rm -it --cap-add NET_ADMIN ubuntu:22.04 bash

# Inside the container, check capabilities
apt-get update && apt-get install -y libcap2-bin
capsh --print

Expected output will show capabilities like:

bash
Current: cap_chown,cap_dac_override,...,cap_net_admin,...
Bounding set: cap_chown,cap_dac_override,...,cap_net_admin,...

Check capabilities of running containers:

bash
# List capabilities for all containers
docker ps -q | xargs docker inspect --format '{{.Name}}: CapAdd={{.HostConfig.CapAdd}} CapDrop={{.HostConfig.CapDrop}}'

Test if the capability works:

bash
# Test NET_ADMIN capability
docker run --rm --cap-add NET_ADMIN ubuntu:22.04 ip link set lo down && echo "Success" || echo "Failed"
4Address seccomp restrictions if capabilities alone do not work

Even with the right capability, seccomp (secure computing mode) may block the required system calls.

Test with seccomp disabled (for debugging only):

bash
docker run --security-opt seccomp=unconfined --cap-add NET_ADMIN your-image

If this works, create a custom seccomp profile:

1. Get Docker's default seccomp profile:

bash
curl -o default-seccomp.json https://raw.githubusercontent.com/moby/moby/master/profiles/seccomp/default.json

2. Modify it to allow required syscalls
3. Use your custom profile:

bash
docker run --security-opt seccomp=custom-seccomp.json --cap-add NET_ADMIN your-image

Warning: Disabling seccomp reduces container security. Only disable for debugging or use a minimal custom profile that allows only required syscalls.

5Handle AppArmor and SELinux restrictions

Security modules like AppArmor (Ubuntu/Debian) or SELinux (RHEL/CentOS) may also block operations.

For AppArmor (Ubuntu/Debian):

bash
# Test with AppArmor disabled (debugging only)
docker run --security-opt apparmor=unconfined --cap-add NET_ADMIN your-image

If you see unknown AppArmor profiles causing issues:

bash
# Remove unknown AppArmor profiles
sudo aa-remove-unknown

For SELinux (RHEL/CentOS/Fedora):

bash
# Check SELinux denials
sudo ausearch -m avc -ts recent

# Test with SELinux in permissive mode (debugging only)
docker run --security-opt label=disable --cap-add NET_ADMIN your-image

Create custom policies for production rather than disabling security modules.

6Fix nested container issues (Docker-in-Docker, LXC)

Running Docker inside LXC or Docker-in-Docker has additional restrictions.

For Docker-in-Docker:

bash
# Run with privileged mode (use with caution)
docker run --privileged -v /var/run/docker.sock:/var/run/docker.sock docker:latest

# Or with specific capabilities for DinD
docker run --cap-add SYS_ADMIN --cap-add NET_ADMIN \
  --security-opt seccomp=unconfined \
  --security-opt apparmor=unconfined \
  docker:dind

For Docker inside LXC:

1. Enable nesting in LXC:

bash
# In LXC config
lxc.include = /usr/share/lxc/config/nesting.conf

2. Grant required capabilities to the LXC container:

bash
# In Proxmox, enable nesting and FUSE in container options
# Or manually add to config:
lxc.cap.drop =
features: nesting=1

For Proxmox: Ensure virtualization is enabled in BIOS and the container has nesting enabled.

7Use --privileged as a last resort

The --privileged flag grants all capabilities and disables security restrictions. Use only when absolutely necessary.

Run a privileged container:

bash
docker run --privileged your-image

What --privileged does:
- Grants ALL Linux capabilities
- Disables seccomp filtering
- Gives access to all host devices
- Mounts /dev and /sys as read-write
- Essentially gives container root-level access to the host

Security implications:
- Container can escape to the host
- Container can access host devices
- Container can modify host kernel parameters
- Breaks container isolation model

Better alternative - identify minimum required capabilities:

bash
# Instead of --privileged, use only what you need
docker run \
  --cap-add NET_ADMIN \
  --cap-add SYS_ADMIN \
  --cap-add MKNOD \
  your-image

In production, always prefer specific capabilities over --privileged.

8Update Kubernetes deployments with security contexts

For containers running in Kubernetes, configure capabilities in the pod security context.

Add capabilities in Kubernetes:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: capability-pod
spec:
  containers:
  - name: app
    image: your-image
    securityContext:
      capabilities:
        add:
          - NET_ADMIN
          - SYS_ADMIN

Drop all and add specific (recommended):

yaml
securityContext:
  capabilities:
    drop:
      - ALL
    add:
      - NET_ADMIN

For privileged pods (use sparingly):

yaml
securityContext:
  privileged: true

Note: Pod Security Policies (PSP) or Pod Security Standards may restrict capabilities. Check with your cluster admin if capabilities are being dropped at the policy level.

Advanced notes

### Understanding Linux Capabilities in Docker

Docker's default capability set is designed to balance functionality with security. The following capabilities are granted by default:

- AUDIT_WRITE: Write to kernel auditing log
- CHOWN: Change file ownership
- DAC_OVERRIDE: Bypass file permission checks
- FOWNER: Bypass permission checks for file owner operations
- FSETID: Set file capabilities
- KILL: Send signals to processes
- MKNOD: Create special files
- NET_BIND_SERVICE: Bind to ports below 1024
- NET_RAW: Use raw sockets
- SETFCAP: Set file capabilities
- SETGID/SETUID: Change process GID/UID
- SETPCAP: Modify process capabilities
- SYS_CHROOT: Use chroot

### Rootless Docker Considerations

Rootless Docker has additional capability limitations because it runs without root privileges on the host:

bash
# Check if running rootless
docker info | grep -i rootless

In rootless mode, some capabilities like CAP_NET_ADMIN may not work even when added because the user namespace doesn't have the required host-level permissions.

Workarounds for rootless mode:
- Run specific operations on the host instead of in the container
- Use slirp4netns for network operations
- Configure /etc/sysctl.conf for required kernel parameters

### Security Best Practices

1. Principle of least privilege: Only add capabilities actually needed
2. Drop all, add specific: Use --cap-drop ALL then add only what's required
3. Test in development: Identify minimum capabilities before production
4. Document requirements: Note why each capability is needed
5. Audit regularly: Review containers for unnecessary privileges

bash
# Recommended secure pattern
docker run \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  --read-only \
  --security-opt no-new-privileges:true \
  your-image

### Debugging Capability Issues

Trace system calls to identify what's blocked:

bash
# Requires SYS_PTRACE capability
docker run --cap-add SYS_PTRACE --security-opt seccomp=unconfined \
  your-image strace -f your-command

Check kernel capability masks:

bash
# Inside container
cat /proc/self/status | grep -i cap

Common capability combinations:

| Use Case | Capabilities Needed |
|----------|-------------------|
| Network tools | NET_ADMIN, NET_RAW |
| Docker-in-Docker | SYS_ADMIN, NET_ADMIN, MKNOD |
| Debugging/profiling | SYS_PTRACE |
| NFS/FUSE mounts | SYS_ADMIN |
| Time synchronization | SYS_TIME |

Frequently asked questions

What does "Error response from daemon: operation not permitted: capability not pe" mean?
When Docker runs a container, it operates with a restricted set of Linux capabilities by default. Linux capabilities are a way to break down the monolithic root privileges into smaller, more granular permissions. Instead of giving a process full root access, the kernel can grant specific capabilities like CAP_NET_ADMIN (network administration) or CAP_SYS_ADMIN (system administration).
How do I fix "Error response from daemon: operation not permitted: capability not pe"?
This error occurs when a Docker container attempts to use a Linux capability that has not been granted. The container is trying to perform a privileged operation (like modifying network interfaces or mounting filesystems) but lacks the required capability. Fix by adding specific capabilities with --cap-add or reviewing your security constraints.
What causes "Error response from daemon: operation not permitted: capability not pe"?
Container attempting to use a Linux capability not in Docker's default set Application requires CAP_NET_ADMIN, CAP_SYS_ADMIN, or other elevated capabilities Running Docker inside LXC containers without proper capability configuration
Is the "Error response from daemon: operation not permitted: capability not pe" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading