Run ./script.sh vs bash script.sh - permission denied
Incorrect POSIX permissions
It means you don't have the execute permission bit set for script.sh
. When running bash script.sh
, you only need read permission for script.sh
. See What is the difference between running “bash script.sh” and “./script.sh”? for more info.
You can verify this by running ls -l script.sh
.
You may not even need to start a new Bash process. In many cases, you can simply run source script.sh
or . script.sh
to run the script commands in your current interactive shell. You would probably want to start a new Bash process if the script changes current directory or otherwise modifies the environment of the current process.
Access Control Lists
If the POSIX permission bits are set correctly, the Access Control List (ACL) may have been configured to prevent you or your group from executing the file. E.g. the POSIX permissions would indicate that the test shell script is executable.
$ ls -l t.sh
-rwxrwxrwx+ 1 root root 22 May 14 15:30 t.sh
However, attempting to execute the file results in:
$ ./t.sh
bash: ./t.sh: Permission denied
The getfacl
command shows the reason why:
$ getfacl t.sh
# file: t.sh
# owner: root
# group: root
user::rwx
group::r--
group:domain\040users:rw-
mask::rwx
other::rwx
In this case, my primary group is domain users
which has had execute permissions revoked by restricting the ACL with sudo setfacl -m 'g:domain\040users:rw-' t.sh
. This restriction can be lifted by either of the following commands:
sudo setfacl -m 'g:domain\040users:rwx' t.sh
sudo setfacl -b t.sh
See:
- Access Control Lists, Arch Linux Wiki
- Using ACLs with Fedora Core 2
Filesystem mounted with noexec option
Finally, the reason in this specific case for not being able to run the script is that the filesystem the script resides on was mounted with the noexec
option. This option overrides POSIX permissions to prevent any file on that filesystem from being executed.
This can be checked by running mount
to list all mounted filesystems; the mount options are listed in parentheses in the entry corresponding to the filesystem, e.g.
/dev/sda3 on /tmp type ext3 (rw,noexec)
You can either move the script to another mounted filesystem or remount the filesystem allowing execution:
sudo mount -o remount,exec /dev/sda3 /tmp
Note: I’ve used /tmp
as an example here since there are good security reasons for keeping /tmp
mounted with the noexec,nodev,nosuid
set of options.
Try
chmod +rx script.sh
this will make the file executable. Then try,
./script.sh
Hope this will work.