Fix 'Permission denied' on Linux when you're already root

You're root and it still says 'Permission denied'? Yeah, that's annoying.

We've all been there. sudo -i, you're sitting at a # prompt, you try to cat a file or chmod a script, and the system tells you to get lost. Don't waste time double-checking your root status — the culprit here is almost always SELinux, a read-only mount, or a file attribute you didn't know existed.

The quick fix (that works 90% of the time)

Run this first:

ls -Z /path/to/file

If you see system_u:object_r:unconfined_t or something weird like container_file_t on a file you're trying to execute, SELinux is blocking you. Root can still get denied by SELinux — that's by design.

To fix it temporarily:

chcon -t bin_t /path/to/file

Or, if you're in a hurry and don't care about security:

setenforce 0

Then try your operation again. If it works, SELinux was the problem. Don't leave enforcement off — set it back with setenforce 1 and fix the context properly.

If SELinux isn't the problem, check mount flags

Here's a weird one. You can be root on a filesystem mounted with noexec and wonder why your script won't run. Or nodev blocking device file creation. Or nosuid if you're messing with setuid binaries.

Check the mount:

mount | grep /path

If you see noexec in the options, remount it with exec:

mount -o remount,exec /path

Same for nodev and nosuid — just swap the flag you need. I've seen this on /tmp in hardened environments and on NFS shares mounted by a junior admin who didn't know better.

Immutable files — the silent blocker

Sometimes a file has the immutable attribute set. Root can't change it, delete it, or rename it unless you unset the attribute first. Classic attack prevention, but also a pain when you're legitimately trying to update something.

Check it with:

lsattr /path/to/file

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

chattr -i /path/to/file

Now you can do what you need. Don't forget to set it back if you were relying on that protection.

Less common variations that still bite people

Here are a few more I've run into:

• NFS root squash: On some NFS servers, root is mapped to nobody by default. Check /etc/exports on the server — if it has root_squash, you're not root on that mount. Add no_root_squash (but seriously, think about the security implications).
• FUSE filesystems: SSHFS, s3fs, etc. often run as the user who mounted them. Root can't bypass that. Unmount and remount as root if needed.
• ACLs: getfacl /path/to/file can show ACLs that override regular permissions. Even root can be blocked by an ACL that explicitly denies access — though that's rare and usually misconfigured.
• Filesystem corruption: If the FS is marked read-only due to errors, you'll get permission denied trying to write. Check dmesg for I/O errors or mount | grep ro.

How to stop this from coming back

Prevention is about knowing your environment. Here's what I do:

1. Check SELinux first every time you hit a weird permission issue. It's not a Linux bug — it's SELinux doing its job.
2. Mount with explicit flags in /etc/fstab. Don't rely on defaults. Write defaults,exec,dev,suid if you need those capabilities.
3. Run lsattr on critical files before you try to modify them. Saves you 10 minutes of head-scratching.
4. Document your NFS exports — especially root_squash settings. If you're in a team, put it in a README. Future you will thank past you.

That's it. Next time you're root and the system says no, run through this checklist. It'll take you 30 seconds instead of 30 minutes.