Linux 'Permission Denied' Fix: 3 Causes That Trip Everyone Up

Cause 1: Wrong File Permissions (Most Common)

If you're getting bash: ./script.sh: Permission denied right after downloading a script or copying it from a USB stick, it's almost always the execute bit missing. I've seen this trip up sysadmins who've been in the game for years, so don't feel bad.

The fix is chmod. You're giving yourself (or your group, or everyone) the right to execute that file. The fastest way:

chmod +x script.sh
./script.sh

But here's the nuance: if you're running a service as a different user, say www-data for a web app, +x alone won't cut it. You need to be specific. For a web server's upload directory, you often want:

chmod -R 755 /var/www/html

This gives the owner read/write/execute, and everyone else read/execute. That's the sweet spot for most web files. If you need to allow uploads, the directory itself needs write for the server user—try chown first, then chmod 755 on files and chmod 775 on the upload folder.

Real-world trigger: you just cloned a repo from GitHub, the scripts came down without execute permissions because of how Git handles file modes on Windows. You try to run ./deploy.sh and boom—permission denied. That's your clue.

Cause 2: Wrong File Ownership

Sometimes the permissions look perfect—rwxr-xr-x—but you still can't touch the file. That's ownership. If the file is owned by root and you're logged in as a regular user, you're locked out unless you use sudo.

Check ownership with:

ls -l /path/to/file

You'll see something like -rw-r--r-- 1 root root. If you need to edit it, you have two options. Use sudo to edit as root, or change ownership to your user:

sudo chown yourusername:yourgroup /path/to/file

I've seen this happen a lot with mounted NTFS or exFAT drives. They mount as root by default, and you can't write to them without ownership changes. The real fix there is to add a line to /etc/fstab so the drive mounts with your user ID. Something like:

UUID=xxxx /mnt/data ntfs-3g uid=1000,gid=1000,umask=022 0 0

Replace uid and gid with your user's IDs (find them with id). This is the kind of fix that saves you from the error every single time you plug in that drive.

Another trigger: you copied files with sudo cp or sudo rsync, and they all landed as root-owned. You'll see the pattern when you ls -l and everything shows root root, but you're working as your normal user.

Cause 3: Read-Only File System (Mount)

This one's sneaky because the error message can be the same. You try to write to a file, and the system says permission denied, but the file permissions and ownership are fine. What gives? The filesystem is mounted read-only.

Check it with:

mount | grep /path/to/mount

If you see ro in the options, that's your problem. The fix depends on why it's read-only. If it's a one-off remount, run:

sudo mount -o remount,rw /path/to/mount

But if it's a system drive stuck read-only due to an unclean shutdown, you might have corruption. For ext4, try:

sudo fsck -f /dev/sdX1

Replace /dev/sdX1 with your actual partition. You'll need to dismount it first, or boot from a live USB. Don't skip this—writing to a corrupted filesystem can make things worse.

The most common trigger I see: an SD card or USB drive that was pulled out without unmounting. The kernel flips it to read-only to prevent data loss. Remounting usually works, but if it keeps reverting, the drive is failing—replace it.

Also, if you're dealing with NFS mounts, check the server-side exports. A client can't write if the server exported the path with ro. That's a settings change on the server, not the client.

These three cover about 95% of the permission denied errors I've debugged over the years. The other 5% involve SELinux or AppArmor, which are a whole other headache—if you're on RHEL-based distros and you've checked everything above, look at ausearch -m avc for SELinux denials. But that's a different article.