Fixing 'Permission Denied' on Linux Files
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 filenameReplace 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 filenameThe 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 filenameReplace 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:
/tmpis often mounted withnoexecfor security.- USB drives formatted as NTFS or FAT32 are often mounted with
noexecby default. - Some cloud storage mounts like
sshfsor NFS shares might restrict execution.
To remount with execution allowed, use:
sudo mount -o remount,exec /path/to/mountpointIf 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 filenameYou'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 filenameThis 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 filenameOn 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
/tmpand get "Permission denied." The 30-second fix (chmod +x) fails because/tmpis mountednoexec. Move the file to~/scripts/and add execute permission there. Done in 10 seconds once you know the trick.
Was this solution helpful?