Linux EPERM (errno 1) — Operation Not Permitted

EPERM (errno 1) means the operating system denied a requested operation because the calling process does not have the required privileges. This error appears when you attempt a privileged action without sufficient rights, such as writing to a protected file, modifying system configurations, or managing kernel parameters. It is distinct from EACCES (errno 13) because EPERM typically involves operations requiring root or specific capabilities, not just file-level permissions.

Common Causes

  • Running a command that requires root without sudo
  • Attempting to bind to a port below 1024 without privileges
  • Modifying system files owned by root
  • Changing kernel parameters without proper capabilities
  • Writing to a filesystem mounted with nosuid or nodev
  • Attempting operations blocked by SELinux or AppArmor policies

How to Fix EPERM

1. Use sudo for Privileged Operations

Most EPERM errors on desktop Linux happen because the command requires root:

# Instead of:
apt update

# Use:
sudo apt update

To run an entire shell session as root:

sudo -i

2. Check File Permissions and Ownership

Inspect the target file to understand who owns it and what permissions are set:

ls -la /path/to/problem/file

Example output:

-rw------- 1 root root 4096 Jun 15 10:00 /etc/shadow

Change ownership if you own the file but it was created by root:

sudo chown $(whoami) /path/to/problem/file

3. Use chmod to Adjust Permissions

Grant yourself the necessary permissions:

# Give yourself read/write access
sudo chmod u+rw /path/to/problem/file

# Give owner full access, group and others read-only
sudo chmod 755 /path/to/problem/directory

# Make a script executable
chmod +x /path/to/script.sh

4. Check SELinux Context (RHEL/CentOS/Fedora)

SELinux can block operations even when Unix permissions are correct:

# Check SELinux status
getenforce

# View the security context of a file
ls -Z /path/to/problem/file

# Temporarily set SELinux to permissive mode for testing
sudo setenforce 0

# Restore correct SELinux context
sudo restorecon -Rv /path/to/problem/file

5. Check AppArmor Profiles (Ubuntu/Debian)

AppArmor may be restricting a program’s access:

# Check AppArmor status
sudo aa-status

# Put a profile in complain mode (log violations instead of blocking)
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

6. Check File Capabilities

Some programs need specific Linux capabilities rather than full root:

# View capabilities on a binary
getcap /usr/bin/ping

# Grant a capability to a binary
sudo setcap cap_net_raw+ep /usr/bin/ping

7. Adjust ulimit Settings

The process may have hit a resource limit:

# View current limits
ulimit -a

# Check open files limit
ulimit -n

# Temporarily increase the limit
ulimit -n 65535

# For persistent changes, edit /etc/security/limits.conf
sudo nano /etc/security/limits.conf

Add a line like:

* soft nofile 65535
* hard nofile 65535

8. Check if Filesystem is Mounted Read-Only

A read-only filesystem will reject all write operations:

# Check mount options
mount | grep " / "

# Remount as read-write if needed
sudo mount -o remount,rw /

Verification

After applying the appropriate fix, retry the command that originally failed. You can also verify your effective user and group with:

id
whoami
groups