operation not permitted: A syscall was blocked by seccomp, capabilities, or a security module

EPERM inside a container usually means a security layer blocked a system call the process is allowed to attempt but not to complete — a dropped capability, a seccomp filter, or SELinux and AppArmor.

Applies to: All Kubernetes versions, Linux nodes

What it means

Containers run with a reduced set of privileges by default: a restricted capability set, a seccomp profile filtering system calls, and often a mandatory access control system on top. operation not permitted means one of those layers refused. The difficulty is that the error is the same regardless of which layer acted, and the application's own log usually reports it as a generic failure of whatever it was doing — binding a low port, changing a file's ownership, mounting something, adjusting a scheduling priority. Working out which layer is responsible is the whole task, and the node's audit log is usually the fastest route to it.

Most common causes

• A capability the process needs was not granted — binding to a port below 1024 needs NET_BIND_SERVICE, for example.
• A seccomp profile blocking a system call the application uses.
• SELinux or AppArmor denying access to a file or a device.
• readOnlyRootFilesystem preventing a write the process expects to be allowed.
• allowPrivilegeEscalation: false blocking a setuid binary.
• An operation that genuinely requires privileges no container should have, such as loading a kernel module.

How to diagnose it

1. Identify the failing operation from the application's log, then map it to the privilege it needs.
2. Read the pod's security context: kubectl get pod POD -o jsonpath='{.spec.containers[*].securityContext}'.
3. Check the node's audit log for denials, which name the layer and the object: ausearch -m AVC for SELinux, or the AppArmor entries in the kernel log.
4. Test with the capability added in a non-production namespace to confirm the diagnosis before changing anything permanent.
5. Check whether Pod Security Admission is enforcing a level that forbids what you are about to add.

How to fix it

1. Add the specific capability the process needs and nothing more. NET_BIND_SERVICE for low ports, not privileged: true.
2. Better, remove the need — run the server on a port above 1024 and map it in the Service.
3. Adjust the seccomp profile if a legitimately needed syscall is blocked, using a custom profile rather than disabling seccomp.
4. Set the correct SELinux context or AppArmor profile rather than disabling the module.
5. Mount an emptyDir at paths the process must write when the root filesystem is read-only.

Notes

Reaching for privileged: true makes almost every instance of this error disappear, and it removes essentially all container isolation at the same time. The narrower fix is nearly always available and is worth the extra step of identifying which capability is actually needed.

Related

• PodSecurity violation — The pod violates the namespace's security standard
• read-only file system — A write failed because the filesystem is mounted read-only

Sources

• Kubernetes documentation — Configure a Security Context for a Pod or Container
• Kubernetes documentation — Pod Security Standards
• Kubernetes documentation — Restrict a Container's Syscalls with seccomp