If Bash reports Permission denied when you run ./hello.sh, first check whether the file has an execute bit and whether you can access its directory. If it is your script and you have checked its contents, chmod u+x ./hello.sh adds execute permission for its owner. Other causes need different fixes.
This guide concerns a local script on Linux. An SSH message such as Permission denied (publickey) is an authentication problem; start with the Ubuntu SSH guide instead.
Reproduce the simple case
In a new, empty test folder, create a file named hello.sh containing:
#!/bin/bash
printf "%s\n" "Hello from Linux"Set its mode to owner read/write, then try to execute it. These commands change only this test file:
chmod 600 ./hello.sh
./hello.sh
printf 'Exit status: %s\n' "$?"The Ubuntu 24.04 test produced Permission denied and exit status 126. Add the owner's execute bit and run it again:
chmod u+x ./hello.sh
./hello.shNow the output is Hello from Linux. The u selects the file's owner; + adds a permission without replacing the others. This is useful when the missing execute bit is the actual fault.
Inspect the file before changing it
pwd
ls -l ./hello.sh
idConfirm that you are in the intended folder and looking at the intended file. In the permission string, the first three permission positions belong to the owner, the next three to the group, and the final three to everyone else. The owner and group names appear alongside them. If the file belongs to another account, adding its owner's execute bit will not automatically grant you access.
A relative path starts in the current working directory. Use our Bash directory navigation guide if you need to return to the script's folder. If the message is actually command not found, use the command lookup checklist instead.
If the execute bit is already present
| Check | Why it matters |
|---|---|
| Parent directories | You need directory search permission to reach the file, even when the file's own mode looks correct. |
| Owner, groups and ACLs | The permissions applicable to your account may differ from those applicable to the owner. An ACL can add access rules beyond the short mode display. |
| Filesystem mount options | A filesystem mounted with noexec can prevent direct execution. |
| Security policy | AppArmor or SELinux may deny an operation independently of the ordinary file mode. |
On systems with util-linux installed, inspect the path and mount with:
namei -l ./hello.sh
findmnt -T ./hello.sh -o TARGET,FSTYPE,OPTIONSCheck each parent directory in the first result. In the second, look for noexec. On managed machines, ask the administrator about an intentional restriction rather than remounting a filesystem to bypass it. Security-policy denials require the relevant policy logs; repeatedly changing the execute bit will not diagnose them.
Should you use bash hello.sh or sudo?
bash ./hello.sh asks Bash to read the file as input, so it does not require that script's execute bit. It does require readable contents and accessible directories. That difference can help diagnose a trusted script, but it does not repair its direct-execution permissions or justify bypassing an intentional restriction.
Do not apply chmod -R 777 to a project or system directory. It gives much broader access than a single missing execute bit requires. Likewise, sudo changes the account running the program; it is not a general repair for a script whose required privileges you have not established.
Sources and verification
Tested September 11, 2026 in a disposable Ubuntu 24.04 container: direct execution without an execute bit returned 126; adding owner execute permission produced the stated output. Mount inspection also ran. ACL, SELinux, AppArmor and noexec-denial scenarios were not independently reproduced. No production file permissions were changed.