Linux: Permission Denied Even as Root

You run a command as root (or with sudo) and Linux still refuses:

-bash: /path/to/file: Permission denied

This is confusing because root is supposed to be all-powerful — it bypasses normal file permission bits entirely. So when root itself is denied, the cause is almost never ordinary permissions. Something else is enforcing a rule that even root has to obey.

Cause 1: The filesystem is read-only

The most common reason. The partition is mounted read-only — either on purpose, or because the kernel remounted it read-only after disk errors.

mount | grep ' / '            # look for "ro," in the options
touch /some/file              # "Read-only file system" confirms it

Remount it read-write (after checking the disk is healthy):

mount -o remount,rw /

If it keeps going read-only, the disk is likely failing — check dmesg for I/O errors.

Cause 2: The file is immutable (chattr +i)

A file can carry an immutable attribute that blocks all writes, deletes, and renames — even by root — until it's cleared.

lsattr /path/to/file          # an 'i' in the flags = immutable
chattr -i /path/to/file       # remove it, then retry

Cause 3: The mount forbids execution (noexec)

If you're trying to run a script or binary and only that fails, the filesystem may be mounted noexec (common on /tmp, /dev/shm, and hardened mounts).

mount | grep noexec           # is the file's filesystem noexec?

Move the binary to a normal filesystem, or remount without noexec.

Cause 4: SELinux or AppArmor is denying it

Mandatory Access Control (MAC) sits above root. On RHEL/Fedora (SELinux) or Ubuntu (AppArmor), a policy can deny an action no matter who you are.

getenforce                    # SELinux: "Enforcing"?
ausearch -m avc -ts recent    # SELinux denials (or check /var/log/audit/audit.log)
dmesg | grep -i apparmor      # AppArmor denials

The fix is to adjust the policy (add the right context/label or an AppArmor rule) — not to blanket-disable security.

The checklist

1. Root being denied ≠ a normal permission problem — root ignores those.
2. Read-only filesystem? mount | grep ' / ', then mount -o remount,rw.
3. Immutable file? lsattr, then chattr -i.
4. Only execution fails? Check for a noexec mount.
5. RHEL/Ubuntu with a denial in the audit log? It's SELinux/AppArmor — fix the policy.

Frequently Asked Questions

Why is root getting "Permission denied"? Because root bypasses ordinary file permissions, so the block is coming from something higher: a read-only filesystem, an immutable (chattr +i) file, a noexec mount, or a security module like SELinux or AppArmor.

How do I fix "permission denied" caused by an immutable file? Run lsattr on the file — an i in the flags means it's immutable. Clear it with sudo chattr -i /path/to/file, then retry. Set it back later with chattr +i if it was intentional.

What's the difference between "Permission denied" and "Operation not permitted" as root? "Permission denied" (EACCES) typically points to a filesystem or MAC restriction. "Operation not permitted" (EPERM) as root usually means an immutable attribute or a missing Linux capability (common inside containers) — check lsattr and, in containers, the granted capabilities.