EACCES / Permission denied

Fixing 'Permission Denied' on Linux Files

Linux & Unix Beginner 👁 0 views 📅 May 27, 2026

Got 'Permission denied' when trying to read or execute a file? Usually it's missing execute permissions or wrong ownership. Here's how to fix it fast.

30-Second Fix: Make the File Executable

The most common reason you see "Permission denied" running a script you just downloaded is that the file doesn't have the execute bit set. This happens with shell scripts (.sh), Python scripts without a shebang, or binaries you compiled yourself. Run this command:

chmod +x filename

Replace filename with your actual file. Now try running it again with ./filename. If that was the issue, you're done. This works because chmod +x adds the execute permission for the owner, group, and others — it's the Linux equivalent of "make this runnable."

Why this works: Linux permissions are split into read (r), write (w), and execute (x). When you download a file, the system often strips the execute bit for safety. Adding it back tells the kernel it's safe to run.

5-Minute Fix: Check Ownership and Group

If chmod +x didn't work, the problem is likely ownership. The file might belong to another user, or you're not in the right group. Check with:

ls -l filename

The output looks like -rwxr-xr-- 1 alice devs 1024 Mar 10 12:00 script.sh. The third column is the owner (alice), the fourth is the group (devs). If you're not alice and not in the devs group, you can't run it even if the execute bits look right.

To fix this, change ownership to your user:

sudo chown yourusername:yourusername filename

Replace yourusername with your actual username (run whoami if you forgot). The :yourusername part sets the group to your primary group, which is usually named after you. After this, you should be able to run the file.

If you can't use sudo, ask the sysadmin to add you to the file's group, or run chmod o+x filename to let anyone execute it. That's less secure but works in a pinch.

15+ Minute Fix: Investigate Mount Options and ACLs

Still stuck? The issue might be deeper — a mount option like noexec, or an ACL (Access Control List) overriding basic permissions. This is common on shared servers, Docker containers, or mounted USB drives.

Check for noexec Mount

Run mount | grep $(df . --output=target | tail -1) to see the mount options for the filesystem your file is on. If you see noexec in the options, the kernel won't let any file execute, regardless of permissions. Common places this happens:

  • /tmp is often mounted with noexec for security.
  • USB drives formatted as NTFS or FAT32 are often mounted with noexec by default.
  • Some cloud storage mounts like sshfs or NFS shares might restrict execution.

To remount with execution allowed, use:

sudo mount -o remount,exec /path/to/mountpoint

If you don't have root access, you're stuck — copy the file to a directory like /home/yourname which is usually mounted with exec.

Check ACLs

ACLs can override standard permissions. Check with:

getfacl filename

You'll see lines like user:someuser:rwx or mask::r-x. The mask is the effective maximum permission for everyone except the owner. If the mask is r--, even chmod +x won't help — the ACL mask blocks it. Fix with:

setfacl -m u:yourusername:rwx filename

This sets an explicit ACL entry for your user with full permissions. Run getfacl again to confirm the mask updated.

Last Resort: Check SELinux or AppArmor

On Red Hat, Fedora, or CentOS, SELinux can deny execution even if file permissions are perfect. Check with ls -Z filename. If the context is wrong (e.g., unconfined_u:object_r:user_home_t:s0 instead of bin_t for executables), restore it:

sudo restorecon -v filename

On Ubuntu/Debian, AppArmor can block execution. Check sudo aa-status for profiles that might be interfering. Disable a profile temporarily with sudo aa-complain /path/to/binary (but don't leave it that way).

If none of this works, the file might be corrupted or the filesystem is read-only. Run dmesg | tail to look for I/O errors. Sometimes the drive is dying, and that's not a permission problem — that's a hardware problem.

Real-world scenario: You download a script from GitHub to /tmp and get "Permission denied." The 30-second fix (chmod +x) fails because /tmp is mounted noexec. Move the file to ~/scripts/ and add execute permission there. Done in 10 seconds once you know the trick.

Was this solution helpful?