Bash script Permission denied: the fix is not sudo

Published September 26, 2026

⏱️ 2 min read

The actual fix

chmod +x script.sh
./script.sh

That is the whole fix in most cases. The error is the filesystem saying you cannot execute this file, and sudo does not grant execute bits, it only bypasses ownership checks.

When chmod is not enough

1. Not in PATH. ./script.sh requires the ./ prefix because the current directory is usually not in PATH. Running script.sh alone gives command not found, not permission denied, so this trips people differently.
2. Filesystem mounted noexec. If chmod +x still refuses (especially in /tmp or mounted volumes), the mount has the noexec flag. mount | grep noexec, then run from a normal directory.
3. Windows line endings. If the error is bad interpreter or the script prints weird /r behavior: dos2unix script.sh. This looks like permission issues but is encoding.
4. Not a script at all. Trying to execute a data file needs a real entrypoint. bash script.sh works without +x, which is why it is the right test for is it the file or the content.

The habit that prevents it

Editors do not preserve execute bits across some file transfers (looking at you, zip downloads and CI artifact copies). After pulling scripts from anywhere: chmod +x once, verify with ls -l. If you script the step in CI, remember runners start fresh every time, so put the chmod inside the pipeline, not in your habits. Need a CI runner you control end to end? a small DigitalOcean droplet as a self-hosted runner is cheaper than most managed CI minutes. (Partner link.)