Linux Permissions Denied Even with Sudo Solution

It’s one of the most confusing moments in Linux: you run a command with sudo and still get “Permission denied.” The good news is that this almost always points to a specific, fixable cause rather than a broken system. Here’s how to diagnose and resolve it.

Why Sudo Doesn’t Always Win

People assume sudo grants unlimited power, but it only elevates the process to root. Several other layers can still block access:

Read also: Ubuntu vs Debian: Key Differences and Which to Choose in 2026

• The filesystem is mounted read-only.
• An immutable attribute is set on the file.
• SELinux or AppArmor is denying the action regardless of user.
• You’re targeting a path on a network or special filesystem with its own rules.
• The “permission denied” actually comes from the shell, not the command.

Cause 1: Read-Only Filesystem

If a disk has errors or was mounted read-only, even root cannot write to it. Check with:

mount | grep ' / '

If you see ro in the options instead of rw, the filesystem is read-only. Remount it writable with sudo mount -o remount,rw /. If it keeps reverting to read-only, the underlying disk likely has errors. Run sudo dmesg | grep -i error and consider an fsck on the affected partition.

Cause 2: The Immutable Attribute

A file can carry the immutable flag, which blocks all modification, deletion, or renaming, even by root. This is a frequent surprise. Check it with:

lsattr filename

If you see an i in the output (e.g. ----i---------), the file is immutable. Remove the flag with sudo chattr -i filename, then your sudo command will work normally.

Cause 3: SELinux or AppArmor Denials

On Fedora, RHEL, and CentOS, SELinux can deny actions that file permissions would otherwise allow. Check its status with getenforce. If it returns Enforcing, look for denials with sudo ausearch -m avc -ts recent. The fix is usually to correct the file’s security context with restorecon rather than disabling SELinux. On Ubuntu, AppArmor plays a similar role; check sudo aa-status and review the relevant profile in /etc/apparmor.d/.

Cause 4: Redirection Runs as Your User, Not Root

This catches almost everyone. When you write:

sudo echo "text" > /etc/protected.conf

the sudo applies only to echo. The > redirection is handled by your shell, which has no permission to write the file. The result is “Permission denied” despite the sudo. The correct approaches are:

1. echo "text" | sudo tee /etc/protected.conf — pipe to tee, which runs as root.
2. sudo tee -a /etc/protected.conf for appending.
3. Or edit interactively with sudo nano /etc/protected.conf.

Quick Diagnostic Checklist

• Confirm the path: a typo can point you at a directory you genuinely can’t touch.
• ls -l and lsattr the target to inspect permissions and attributes.
• mount to confirm the filesystem is read-write.
• getenforce / aa-status to rule out mandatory access control.
• Reconsider whether a shell redirection is the real culprit.

Frequently Asked Questions

Why does sudo echo to a file still say permission denied?

Because the shell performs the > redirection as your normal user before sudo ever runs. Use echo "text" | sudo tee /path/file instead, since tee executes with root privileges.

How do I check if a file is immutable?

Run lsattr filename. An i in the attribute list means it’s immutable. Remove it with sudo chattr -i filename.

Can SELinux block root from accessing a file?

Yes. SELinux enforces policy independently of user identity. Check getenforce and audit denials with ausearch -m avc, then fix the file context using restorecon rather than turning SELinux off.

What if the whole filesystem is read-only?

Remount it with sudo mount -o remount,rw /. If it returns to read-only on its own, the disk likely has errors; check dmesg and run fsck on the partition.