Fixing 'Permission denied' on Linux: 3 causes

1. File permissions and ownership are wrong (most common)

You've seen it a hundred times: you try to open a script or a config file, and the shell spits back Permission denied. Nine times out of ten, the culprit is the file's mode bits or owner. The system checks the owner, then the group, then everyone else. If you're not the owner and not in the group, you get nothing.

Let's say you're trying to run a script called deploy.sh that sits in a shared directory. The user who owns it is root, and the group is root, but you're logged in as joel. Running ./deploy.sh gives you bash: ./deploy.sh: Permission denied. The script isn't executable by you.

Here's how you check:

ls -l deploy.sh
-rw-r--r-- 1 root root 1024 Jan 15 10:00 deploy.sh

Notice the -rw-r--r-- — no 'x' for anyone. To fix it, you need to either change ownership or add execute permission. If you have sudo, do either:

sudo chmod +x deploy.sh    # makes it executable for everyone
sudo chown joel:joel deploy.sh   # gives you ownership

For regular files you need to read or write, check the group. If the file is owned by www-data and your user isn't in that group, you'll get Permission denied when trying to edit it. Add your user to the group:

sudo usermod -a -G www-data joel

Then log out and back in for the group change to take effect. That's a classic — you add the user to the group, but the running session still has the old group list. newgrp www-data can also work if you don't want to log out.

2. ACLs are overriding basic permissions

ACLs (Access Control Lists) add an extra layer of rules that can stomp on your expected behavior. You can have perfect chmod settings and still get Permission denied because an ACL entry is blocking you. This happens a lot on shared file servers or after someone used setfacl to grant access to a specific user and later forgot about it.

Check for ACLs with:

getfacl /path/to/file

If you see lines like user:joel:--- or mask::r--, that's your issue. The mask limits the maximum permissions for named users and groups, even if the group bits say otherwise. Say the file has group::rw- but mask::r-- — the effective group permission is read-only.

Fix it by either removing the specific ACL entry or the whole ACL:

setfacl -x u:joel /path/to/file   # remove a specific user entry
setfacl -b /path/to/file          # remove ALL ACL entries

If you need to grant access, you can add an ACL entry instead of messing with chmod:

setfacl -m u:joel:rwx /path/to/file

But be careful — ACLs can be a trap. They don't show up with ls -l; you'll see a + at the end of the mode string, like -rw-rw-r--+. That plus sign is a red flag that ACLs are in play. Ignore it at your own peril.

3. Mount options are too restrictive

This one sneaks up on you when you mount external drives, network shares, or removable media. The filesystem might have proper permissions, but the mount options override them. The usual suspects are noexec, nodev, and nosuid — but also ro (read-only). If you mount a USB drive with ro, you won't be able to write to it no matter what the file permissions say.

A typical scenario: you mount a Windows partition for dual-boot access. You get Permission denied when trying to create a file, even though you own the mount point. Check the mount options:

mount | grep /media/joel/Windows

You'll likely see something like ntfs-3g ... rw,noexec,nodev,nosuid — or worse, ro.

To fix it, remount with the right options. For an NTFS drive, you make sure it's read-write and possibly set the uid/gid to your user:

sudo mount -o remount,rw,uid=joel,gid=joel /media/joel/Windows

For a permanent fix, edit /etc/fstab. Find the line for that drive and update the options. A typical entry for a Windows partition might look like:

/dev/sda2 /media/joel/Windows ntfs-3g defaults,uid=joel,gid=joel,umask=022 0 0

And for NFS shares, if the server exports with root_squash or noexec, that can cause similar issues. Check the server's /etc/exports file. Also remember that NFS by default doesn't let root write unless you specify no_root_squash — but that's a security risk, so only do it on trusted networks.

The key is to always check mount output when you're getting permission errors on anything that looks like a drive or partition. The filesystem might be fine — the mount is just restricting you.

Quick reference table

That covers the three big ones. Next time you see this error, don't panic. Run ls -l, then getfacl, then mount. One of them will tell you what's wrong. And remember — if you're on a shared system, ACLs are a common gotcha. They're powerful but easy to misuse.