Linux 'Permission denied' on regular files? Fix it now

The 30-second fix: Check owner, permissions, and file flags

You're in a directory, you see myfile.txt, and cat myfile.txt throws Permission denied. I've been there—it's maddening when the file clearly exists. Let's rule out the obvious first.

1. Run ls -la myfile.txt. Look at the first column (e.g., -rw-r--r--). If the owner is root and you're not root, that's your problem. Also check if there's an i (immutable) flag in the output—e.g., -rw-r--r-- 1 root root 0 Jan 1 12:00 myfile.txt with no extra flag? Good. If you see an i somewhere in the permissions line (sometimes shown with lsattr), that file is locked down.
2. Check the directory permissions: ls -ld .. If the directory lacks execute (x) for you, you can't access any files inside, even if the file itself is readable. That one tripped me up the first time too.
3. Quick fix: chmod u+r myfile.txt if you're the owner. If not, sudo chown $USER: myfile.txt (only if you have sudo).

If that didn't work, move to the moderate fix—it's probably ACLs or a weird mount.

5-minute fix: Check ACLs and mount options

Standard permissions look right? The file shows -rw-r--r-- and you're the owner? Then ACLs are the usual suspect. I've seen this on shared NFS drives or ext4 partitions with custom ACLs.

1. Run getfacl myfile.txt. If you see entries like user:someuser:--- or mask::---, ACLs are blocking you. Example output:

   # file: myfile.txt
   # owner: you
   # group: you
   user::rw-
   user:someuser:---
   mask::---
   other::r--

   The mask entry overrides standard permissions for named users/groups. A mask of --- means no one but the owner can read it.
2. Fix: setfacl -m mask::r-- myfile.txt to allow read. If you want to remove all ACLs: setfacl -b myfile.txt.
3. Still broken? Check mount options: mount | grep $(df . | tail -1 | awk '{print $1}'). Look for noexec, nosuid, nodev. If you see noexec, you can still read and write files, but you can't execute them—but that shouldn't block reading. However, an ro (read-only) mount will. If it's ro, remount with sudo mount -o remount,rw /mount/point.

If you're still getting denied after this, it's time for the deep fix.

15+ minute fix: SELinux, AppArmor, or LSM interference

When permissions and ACLs look perfect but the system still says no, it's a mandatory access control system. I've spent hours on this with RHEL and Ubuntu servers. Here's the drill.

1. Check if SELinux is enforcing: getenforce. If it says Enforcing, run ls -Z myfile.txt. You'll see something like system_u:object_r:etc_t:s0. If that context doesn't match what the process expects (e.g., a web server needs httpd_sys_content_t), you get denial.
2. View the audit log: sudo ausearch -m avc -ts recent or sudo journalctl -x | grep -i denied. Look for denied { read } for your file.
3. Fix the context: sudo chcon -t httpd_sys_content_t myfile.txt (replace with the correct type). Or use semanage fcontext for a permanent fix: sudo semanage fcontext -a -t httpd_sys_content_t /path/to/myfile.txt && sudo restorecon -v /path/to/myfile.txt.
4. For AppArmor (Ubuntu/Debian), check with sudo aa-status. If a profile is blocking access, either adjust the profile in /etc/apparmor.d/ or set the profile to complain mode temporarily: sudo aa-complain /path/to/binary.
5. As a last resort—and I mean last—you can disable SELinux temporarily: sudo setenforce 0. Don't leave it off. Re-enable with sudo setenforce 1 and fix the context properly.

I know this error is infuriating, especially when the file stares you in the face. Nine times out of ten, it's either a directory missing execute permission or an ACL mask. Try the 30-second fix first. If that fails, jump to ACLs. Only go to SELinux if you're on a security-hardened distro like RHEL or CentOS. You'll have that file open in no time.