Fix 'Permission denied' for files you own on Linux

Yeah, that 'Permission denied' error when you try to read, write, or execute a file you own is annoying. Especially when you double-check and you're definitely the owner. Here's the real fix.

The quick fix (2 commands)

Run these two commands from the terminal. Replace /path/to/your/file with the actual path.

chmod 755 /path/to/your/directory
chmod 644 /path/to/your/file

Wait — that's not the file path. You need the parent directory for the first command. So if your file is at /home/you/documents/report.txt, you run:

chmod 755 /home/you/documents
chmod 644 /home/you/documents/report.txt

After running chmod 755 on the directory, you should be able to ls -l that directory and see the file. After chmod 644 on the file, you'll be able to read it. If it's a script you need to run, use chmod 755 on the file instead (gives execute permission).

If you still get 'Permission denied' after this, skip to the 'Less common variations' section below.

Why this works

Linux permissions work in layers. The operating system checks three things when you try to access a file:

1. The file's own permissions (read, write, execute for owner, group, others)
2. The parent directory's permissions (needs read and execute for you to list or traverse it)
3. Any ACLs or special attributes (less common — we'll cover those later)

You can have a file with 777 permissions (full access for everyone), but if the directory containing it has no read or execute permission for you, you can't even see the file exists. The error message is misleading — it says 'Permission denied' on the file, but the problem is really one level up.

The 755 permission on a directory means: owner can read, write, and traverse; everyone else can read and traverse. That's the standard for directories in most systems. The 644 on a regular file means owner can read and write; everyone else can only read. That's the standard for documents.

Less common variations of this issue

1. The file is immutable (chattr)

Sometimes someone (or a script) set the immutable attribute on the file. Run this to check:

lsattr /path/to/your/file

If you see an i in the output (like ----i---------), that file can't be modified, deleted, or renamed by anyone — even root. Fix it with:

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

This happens a lot when security tools harden a system, or when you restore files from backup software that preserves attributes.

2. SELinux or AppArmor is blocking you

If you're on Red Hat, Fedora, CentOS, or any distro with SELinux enabled by default, standard permissions might not be enough. Check if SELinux is blocking access:

ls -Z /path/to/your/file
ls -Zd /path/to/your/directory

You'll see something like unconfined_u:object_r:user_home_t:s0. If the context looks wrong (like httpd_sys_content_t in your home folder), restore it:

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

For AppArmor (Ubuntu, Debian), check sudo aa-status to see if a profile is confining the application trying to access the file.

3. The file has extended ACLs overriding base permissions

Run getfacl /path/to/your/file. If you see lines like user:someuser:--- or mask::---, those ACLs can restrict you even if the base chmod permissions look fine. Clear them with:

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

ACLs are often set by backup tools, file sync apps, or when copying from NTFS or ext4 drives with different permission systems.

4. NFS or network mount with root squash

If the file is on a network share mounted via NFS, the server might have root_squash enabled. That means even if you're root locally, you're mapped to nobody on the server. Check your mount options with mount | grep nfs. If you see root_squash, you need to either use a non-root user or ask the server admin to change the export options.

How to prevent this from happening

Three habits will save you from 90% of 'Permission denied' headaches:

1. Always set directory permissions to 755 and file permissions to 644 when creating new content. If it's a script you'll run often, use 755 on the file.
2. Use umask 022 in your shell startup (.bashrc or .profile). This makes every new file you create default to 644 and every new directory default to 755.
3. When copying files from another system (USB drive, server, cloud), run chmod -R 755 /path/to/copied/dir and chmod -R 644 /path/to/copied/dir (with find to target only files) after the copy. This resets any weird permissions that came with the transfer.

That's it. The fix is almost always the parent directory, but if that doesn't solve it, check attributes, SELinux, ACLs, or your mount options. You'll remember this the next time you hit that error — trust me.