Fix 'Operation not permitted' on Linux when running commands as root

You're not crazy — this happens to everyone

You've got root. You ran sudo or you're logged in as root. And you still get Operation not permitted. I've seen this break pings, prevent starting services, and stop cron jobs dead. Let's fix it.

Step one: check for file capabilities

Modern Linux systems use capabilities instead of raw setuid. Sometimes a package update or a manual change strips or corrupts them. Check the binary that's failing. For ping:

getcap /usr/bin/ping

If you see cap_net_raw=ep or similar, capabilities are set. If you see nothing, that's your problem. Fix it:

setcap cap_net_raw+ep /usr/bin/ping

Replace ping with whatever binary is throwing the error. Common ones: traceroute, arping, ntpdate. I've also seen this on custom compiled tools that forgot to set capabilities.

Step two: check SELinux

SELinux doesn't care if you're root — it enforces policy regardless. Run ausearch -m avc -ts recent to see if SELinux denied the action. If you see AVC denials, you have two choices:

• Quick fix: Temporarily set SELinux to permissive: setenforce 0. Test. If it works, you've confirmed SELinux is the blocker.
• Proper fix: Use audit2allow to generate a policy module. Or restore default contexts: restorecon -v /path/to/binary.

Don't leave SELinux in permissive. That's asking for trouble. Write a proper policy — it takes ten minutes and saves you a headache later.

Step three: check for immutable or append-only attributes

I've seen admins accidentally set chattr +i on a log file or binary. That flag makes the file immutable — even root can't modify or delete it. Check with:

lsattr /path/to/suspect/file

If you see an i in the output, that's your culprit. Remove it:

chattr -i /path/to/suspect/file

Also look for a (append-only). Same fix, different flag.

Less common variants of this error

Kernel security modules (LSM) like AppArmor

Ubuntu and Debian use AppArmor by default. If you're there, check aa-status. You might need to adjust the profile for the offending binary. For example, aa-complain /usr/bin/ping to switch to complain mode, then test.

Filesystem mounted with 'noexec' or 'nodev'

If the binary is on a noexec mount, even root can't execute it. Check mount | grep noexec. Remount with mount -o remount,exec /path.

Kernel capabilities bounding set

In container environments (Docker, LXC), the kernel might drop capabilities from the bounding set. Check cat /proc/self/status | grep CapBnd. If you're missing a required capability, you need to adjust the container's configuration — add --cap-add=NET_RAW to your Docker run command, for example.

Filesystem bug with NFS v4 ACLs

Rare, but I've hit it: NFS mounts with noacl option can cause EPERM on file operations even with correct Unix permissions. Add noacl to your mount options.

How to prevent this from happening again

1. Track capability changes. When you update a package that uses capabilities, verify with getcap afterward. Write a cron job that checks critical binaries and emails you if capabilities change.
2. Audit SELinux denials weekly. Use ausearch or set up setroubleshoot to alert you. Don't wait until something breaks.
3. Never use chattr +i on system binaries. If you need immutability, use SELinux or AppArmor — they're designed for this. chattr is a sledgehammer.
4. Test your backups restore with capabilities intact. Many backup tools (looking at you, old versions of tar) don't preserve extended attributes. Use star or rsync -X.

That's it. Run through these steps in order and you'll fix 99% of 'Operation not permitted' errors. Don't waste time with chmod 777 — that's not solving the real problem, it's just making things insecure.