Fix 'bash: ./script.sh: Permission denied' on Linux

You're in a terminal, you've written a perfectly good shell script, and you type ./script.sh. Instead of running, you get bash: ./script.sh: Permission denied. It happens when you just downloaded a script from the internet, or when you created one in a mounted drive like /mnt/usb or /media/username/Drive.

Why this happens

The kernel checks two things before letting you execute a file: the file's permission bits and the mount options of the filesystem it lives on. The most common cause is that the file doesn't have the execute bit set. When you create a script with a text editor, the default permissions are usually -rw-r--r--, which means owner can read and write, everyone else can only read. No execute bit, so the shell says "Permission denied."

Another cause, especially on USB drives or separate partitions, is the filesystem being mounted with the noexec option. That tells the kernel to ignore execute permissions entirely. Even if you chmod +x the script, it won't run.

First, check the file's permissions

Run this command:

ls -l script.sh

You'll see something like:

-rw-r--r-- 1 user user  1234 Jan 15 10:00 script.sh

The first ten characters show the type and permissions. If you don't see an x anywhere (like -rwxr-xr-x), that's your problem.

Fix: add execute permission

To make the script executable for your user only, use:

chmod u+x script.sh

If you want everyone to be able to run it, use:

chmod +x script.sh

Now check again with ls -l script.sh. You should see an x in the permission string. Then try running it:

./script.sh

If it runs, you're done. If you still get the same error, read on.

If it still fails: check for a noexec mount

If your script is on a mounted filesystem, find out where it's mounted with:

df -h script.sh

That shows the device and mount point. Then check the mount options:

mount | grep /path/to/mountpoint

Look for noexec in the options list. Example output:

/dev/sdb1 on /media/username/USB type vfat (rw,noexec,nosuid,nodev)

Notice the noexec there. That's the culprit.

How to run a script on a noexec filesystem

You have two options. The easy one: copy the script to your home directory and run it there.

cp script.sh ~/script.sh
chmod +x ~/script.sh
~/script.sh

If you must run it in place, you can invoke the interpreter directly. That bypasses the need for the execute bit:

bash script.sh

Or if it's a script with a shebang, like #!/usr/bin/python3, use:

python3 script.sh

That works because you're not executing the file itself, you're telling an interpreter to read and run its contents.

Remounting with exec (advanced, not always possible)

If the drive is yours and you want to allow execution permanently, you can remount it with the exec option. For a USB drive, unmount it and mount again:

sudo umount /media/username/USB
sudo mount -o exec /dev/sdb1 /media/username/USB

That changes the session only. To make it persist across reboots, you'd edit /etc/fstab and add the exec option for that partition. Don't do that unless you understand the security implications.

What if it's not the permissions or mount?

If you've checked both and still get Permission denied, look at the filesystem type. If it's a Windows-formatted drive (NTFS or FAT32), Linux may not fully support execute permissions on those. Check with df -T script.sh to see the filesystem type. If it says ntfs or vfat, that's your issue.

Another rare cause is that the script has a Windows line ending (CRLF). That won't cause a permission error, but it might cause a different error like bad interpreter. If you see that, run sed -i 's/\r$//' script.sh to strip the carriage returns.

Also check the file's owner. If you're not the owner and you don't have group write permissions, you might need sudo. But that usually gives a different error.

For most cases, the chmod +x fix does it. This error appears constantly with downloaded scripts because browsers and file managers don't preserve the execute bit. Just remember to set it manually after downloading.