Why Your Bash Script Says Permission Denied
Seeing "permission denied" when you run a Bash script is common and usually means the file lacks an execute bit, the interpreter can’t be found, or your environment blocks access. This guide explains the causes and shows exact fixes so you can run scripts confidently on Linux and macOS.
Two Requirements to Run a Script
For any script to execute, the operating system needs two things: the file must be marked as executable, and the kernel must be able to locate a valid interpreter. If either check fails, you get a permission-denied error even when you own the file. Understanding these checks helps you diagnose the problem quickly.
Interpreting Linux File Mode Bits
Each file has permission bits split into three classes: owner, group, and others. For scripts, you typically need read permission to open the file and execute permission to run it as a program. Without the execute bit, the shell refuses to run it and returns permission denied.
The Role of the Shebang
The shebang (#!/bin/bash or similar) tells the kernel which interpreter to use. If the path is wrong, the interpreter is missing, or the interpreter itself lacks permissions, execution fails. A missing or incorrect shebang is a frequent cause of script failures that look like permission issues.
Common Causes and Fixes
Most "permission denied" cases can be solved with a few reliable steps: add the execute bit, verify the shebang, ensure the interpreter exists, avoid unnecessary sudo, and confirm your PATH and working directory. The fixes below are safe and work across distributions and macOS.
Cause 1: Missing Execute Bit
The most straightforward cause is that the file does not have the execute bit set. You can add it with chmod +x script.sh or chmod u+x script.sh for user-only access. After setting the bit, test the script again.
Cause 2: Incorrect or Missing Shebang
If the first line of your script does not start with #!/path/to/interpreter, the kernel may not know how to run it. Use #!/bin/bash for Bash scripts and verify that /bin/bash exists with command -v bash or which bash.
Cause 3: Interpreter Not Installed or Not in PATH
When the shebang points to an interpreter that is missing or outside the shell’s PATH, execution can be blocked. Confirm interpreter availability with which bash or type bash and install missing packages if needed.
Cause 4: Using Sudo When Not Needed
Running scripts with sudo can introduce root-only PATH and environment rules that block execution. Prefer fixing permissions and ownership instead of sudo. Reserve sudo for cases where the script must write to protected locations.
Quick Diagnostic Checklist
Use this checklist to systematically narrow the cause. Check permissions, shebang, interpreter availability, ownership, and environment variables. This approach reduces trial-and-error and speeds up fixes.
| Check | Command | What to Look For |
|---|---|---|
| Execute bit | ls -l script.sh | Look for x in the owner or other permission field |
| Shebang line | head -1 script.sh | Must start with #! and a valid interpreter path |
| Interpreter exists | which bash | Should return a path like /bin/bash |
| File ownership | \nls -ln script.sh | \nOwner and group should match your user when not using sudo | \n
| Working directory | \npwd and ls ./script.sh | \nRun with ./script.sh when using a relative path | \n
Safe Troubleshooting Steps
Follow these steps in order to resolve the issue without introducing security risks. Each step isolates one possible cause so you can confirm what actually fixed the problem.
- Confirm you are in the correct directory and referencing the script name accurately, for example ./script.sh.
- Add the execute bit with chmod u+x script.sh or chmod +x script.sh.
- Verify and correct the shebang line to point to an existing interpreter.
- Check that the interpreter exists using which bash or command -v bash.
- Avoid using sudo unless the script must write to system locations, and then only for the specific commands that need it.
Security and Best Practices
Keep execute bits limited to trusted users and avoid broad permissions like 777. Prefer directories like ~/bin for user scripts and use full paths or add your directory to PATH safely. Never make scripts world-writable, and review ownership regularly to prevent accidental privilege escalation.
When to Suspect Deeper Issues
If standard fixes do not work, consider filesystem restrictions, mounted options like noexec, or mandatory access controls such as SELinux or AppArmor. In containerized environments, verify that the runtime allows exec permissions and that the base image includes the required interpreter. These advanced checks help resolve stubborn cases.