Fix 'Permission Denied' on Linux files (even with sudo)

Quick answer

Run sudo lsattr /path/to/file. If you see an i flag, run sudo chattr -i /path/to/file. Then use sudo chmod 644 /path/to/file or sudo chown youruser:youruser /path/to/file.

Why this happens

You're sitting there, trying to change a system config file or edit a script. You type sudo nano /etc/somefile, and boom: Permission denied. You try sudo chmod 777 on it. Same error. You're root, right? Why won't it let you?

This used to drive me crazy back when I ran a help desk blog. I'd get emails every week: "Priya, I'm root! Why can't I save this file?" The answer is almost always: the file has the immutable attribute set. That's the Linux chattr flag +i. Even root can't modify it unless you remove that flag first. It's a security feature — but it's a pain when you're trying to fix something.

Common triggers: editing /etc/resolv.conf on systems like Ubuntu 22.04, touching /etc/hosts on Docker containers, or trying to change network configs on RHEL 9. The immutable flag protects critical files from accidental changes. But when you need to change them, it's infuriating.

Step-by-step fix

Step 1: Check the file attributes

Open a terminal. Run this command:

sudo lsattr /path/to/your/file

You'll see a bunch of letters. Look for ----i-------- or i in the output. That's your culprit.

Step 2: Remove the immutable flag

If you see the i flag, run:

sudo chattr -i /path/to/your/file

No output means it worked. Run sudo lsattr again to confirm the i is gone.

Step 3: Fix permissions or ownership

Now you can set the right permissions. Usually 644 for normal files, 755 for scripts:

sudo chmod 644 /path/to/your/file

Or change ownership to your user:

sudo chown yourusername:yourusername /path/to/your/file

Step 4: Edit the file

Now try editing again. Should work fine.

sudo nano /path/to/your/file

Alternative fixes if the main one doesn't work

Check SELinux or AppArmor

If lsattr shows no i flag, but you still get permission denied, it might be SELinux. On RHEL, CentOS, Fedora, run:

ls -Z /path/to/your/file

You'll see a SELinux context. If it says unconfined_u:object_r:default_t or something weird, restore the default context:

sudo restorecon -v /path/to/your/file

For AppArmor (Ubuntu/Debian), check logs with sudo journalctl -xe for AppArmor denials.

Check ACLs (Access Control Lists)

Sometimes ACLs override standard permissions. Run:

getfacl /path/to/your/file

If you see user:someuser:rwx but you're not that user, you can clear the ACL:

sudo setfacl -b /path/to/your/file

Is the filesystem mounted read-only?

This one tripped me up on a production server once. Run:

mount | grep /path

If you see ro (read-only), remount it as read-write:

sudo mount -o remount,rw /dev/sda1 /path

(Replace /dev/sda1 with your actual device from the mount command.)

How to prevent this

If you're a sysadmin, you might want to keep the immutable flag on some files. That's fine. But when you need to edit them, you'll remember this fix.

For normal users: don't set the immutable flag on your own files. It's overkill. Only system config files should have it.

If you're writing scripts that modify config files, add a check:

if lsattr /etc/resolv.conf | grep -q 'i'; then
    sudo chattr -i /etc/resolv.conf
fi

That way your script won't crash on the first run.

Also: never use chmod 777 as a workaround. It's lazy, and it creates security holes. The real fix is the immutable flag or a misconfigured SELinux policy. Go fix the root cause.

That's it. You're not crazy — the file really was protected from root. Now you know the trick.