Linux EPERM (errno 1) — Operation Not Permitted (Deep Dive)
About Linux EPERM (errno 1)
Deep dive into Linux EPERM error covering capability-based permissions, namespace restrictions, AppArmor/SELinux denials, and advanced troubleshooting beyond simple sudo. This guide covers everything you need to know about this topic, including common causes, step-by-step solutions, and answers to frequently asked questions.
Here are the key things to understand: EPERM (errno 1) means the process lacks the required privilege for the operation. Different from EACCES (errno 13): EPERM is about capability/privilege, EACCES is about file permissions. Linux capabilities (CAP_NET_ADMIN, CAP_SYS_ADMIN, etc.) provide fine-grained privilege control. SELinux and AppArmor Mandatory Access Control can return EPERM even for root. Container namespaces restrict capabilities even when running as UID 0 inside the container. Understanding these fundamentals will help you diagnose and resolve this issue more effectively.
The most common reasons this occurs include: Process running without required Linux capability (e.g., CAP_NET_RAW for raw sockets). SELinux denying the operation based on security context. AppArmor profile restricting the operation. Running inside a container with dropped capabilities. Immutable file attribute set (chattr +i) preventing modification even by root. Identifying the root cause is the first step toward finding the right solution.
To resolve this, follow these recommended steps: Check if SELinux is blocking: ausearch -m avc -ts recent or check /var/log/audit/audit.log. Check AppArmor: dmesg | grep apparmor for denial messages. Check immutable attribute: lsattr /path/to/file — 'i' means immutable, remove with chattr -i. Check required capabilities: capsh --print to see current process capabilities. For containers: add needed capability with --cap-add=CAP_NAME in docker run. If these steps do not resolve the issue, consider consulting additional resources or a qualified professional.
This article is part of our Linux Error Codes collection on Error Codes Wiki. We provide comprehensive, up-to-date information to help you find solutions quickly.
Quick Answer
Why does sudo not fix EPERM?
SELinux/AppArmor can deny root. Immutable attributes block even root. Container namespaces limit capabilities. These go beyond simple privilege escalation.
Overview
Deep dive into Linux EPERM error covering capability-based permissions, namespace restrictions, AppArmor/SELinux denials, and advanced troubleshooting beyond simple sudo.
Key Details
- EPERM (errno 1) means the process lacks the required privilege for the operation
- Different from EACCES (errno 13): EPERM is about capability/privilege, EACCES is about file permissions
- Linux capabilities (CAP_NET_ADMIN, CAP_SYS_ADMIN, etc.) provide fine-grained privilege control
- SELinux and AppArmor Mandatory Access Control can return EPERM even for root
- Container namespaces restrict capabilities even when running as UID 0 inside the container
Common Causes
- Process running without required Linux capability (e.g., CAP_NET_RAW for raw sockets)
- SELinux denying the operation based on security context
- AppArmor profile restricting the operation
- Running inside a container with dropped capabilities
- Immutable file attribute set (chattr +i) preventing modification even by root
Steps
- 1Check if SELinux is blocking: ausearch -m avc -ts recent or check /var/log/audit/audit.log
- 2Check AppArmor: dmesg | grep apparmor for denial messages
- 3Check immutable attribute: lsattr /path/to/file — 'i' means immutable, remove with chattr -i
- 4Check required capabilities: capsh --print to see current process capabilities
- 5For containers: add needed capability with --cap-add=CAP_NAME in docker run