🔧 Error Fixes
· 2 min read
Last updated on

Linux: Permission Denied When Running Script — How to Fix It


You try to run a script and the terminal slaps you with:

bash: ./script.sh: Permission denied

You know the file exists. You can see it right there. But Linux won’t let you execute it.

What causes this

Every file on Linux has three permission sets: read (r), write (w), and execute (x) — for the owner, the group, and everyone else. When you create a new file (or clone a repo, or download a script), it typically doesn’t have the execute bit set.

The Permission denied error means the current user doesn’t have execute permission on that file. This happens when:

  • You created the script with a text editor (editors don’t set the execute bit)
  • You downloaded the file from the internet
  • You cloned a repo where the execute bit wasn’t tracked (Git does track it, but not all tools preserve it)
  • The file is on a filesystem mounted with noexec (common for /tmp on hardened systems)
  • The file is owned by another user and you don’t have the right group permissions

Fix 1: Add execute permission

The most common fix. Give the file execute permission:

chmod +x script.sh
./script.sh

If you want to be more specific about who gets execute permission:

# Only the owner
chmod u+x script.sh

# Owner and group
chmod ug+x script.sh

# Everyone (use with caution)
chmod a+x script.sh

Fix 2: Run with the interpreter directly

You don’t actually need execute permission if you invoke the interpreter yourself:

bash script.sh

Or for other languages:

python3 script.py
node script.js

This works because you’re executing bash (which you do have permission to run), and bash reads the script file — it only needs read permission for that.

Fix 3: Check file ownership

If chmod +x gives you a permission error too, the file is probably owned by another user:

ls -la script.sh
# -rw-r--r-- 1 root root 1234 Mar 16 10:00 script.sh

If it’s owned by root or another user:

sudo chown $(whoami) script.sh
chmod +x script.sh

Or just run it with sudo if it’s meant to be a system script:

sudo ./script.sh

Fix 4: Check the filesystem mount options

If you’re running a script from /tmp or an external drive and chmod +x seems to have no effect:

mount | grep $(df script.sh --output=source | tail -1)

Look for noexec in the output. If the filesystem is mounted with noexec, you can’t execute anything on it regardless of file permissions. Copy the script to your home directory instead:

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

How to prevent it

  • Add a chmod +x step in your README when distributing scripts
  • Use git update-index --chmod=+x script.sh to track the execute bit in Git
  • If you’re writing a Makefile or CI pipeline that generates scripts, add chmod +x right after creating them
  • Use a shebang line (#!/bin/bash) at the top of your scripts — it doesn’t fix permissions, but it makes the intent clear and helps when using Fix 2