執行 ./script.sh vs bash script.sh - 權限被拒絕

當我嘗試跑步時，./script.sh我得到了Permission denied但是當我跑步時bash script.sh一切都很好。

我做錯什麼了？

POSIX 權限不正確

這意味著您沒有為script.sh. 執行時bash script.sh，只需要讀取權限即可script.sh。請參閱執行“bash script.sh”和“./script.sh”有什麼區別？了解更多資訊。

您可以通過執行來驗證這一點ls -l script.sh。

您甚至可能不需要啟動新的 Bash 程序。在許多情況下，您可以簡單地在目前互動式 shell 中執行source script.sh或執行腳本命令。. script.sh如果腳本更改目前目錄或以其他方式修改目前程序的環境，您可能希望啟動一個新的 Bash 程序。

訪問控制列表

如果正確設置了 POSIX 權限位，則可能已配置訪問控制列表 (ACL) 以阻止您或您的組執行該文件。例如，POSIX 權限將表明測試 shell 腳本是可執行的。

$ ls -l t.sh
-rwxrwxrwx+ 1 root root 22 May 14 15:30 t.sh

但是，嘗試執行該文件會導致：

$ ./t.sh
bash: ./t.sh: Permission denied

該getfacl命令顯示原因：

$ getfacl t.sh
# file: t.sh
# owner: root
# group: root
user::rwx
group::r--
group:domain\040users:rw-
mask::rwx
other::rwx

在這種情況下，我的主要組domain users已通過使用sudo setfacl -m 'g:domain\040users:rw-' t.sh. 可以通過以下任一命令解除此限制：

sudo setfacl -m 'g:domain\040users:rwx' t.sh
sudo setfacl -b t.sh

看：

• 訪問控制列表，Arch Linux Wiki
• 在 Fedora Core 2 中使用 ACL

使用 noexec 選項掛載的文件系統

最後，在這種特定情況下無法執行腳本的原因是腳本所在的文件系統是使用該noexec選項掛載的。此選項覆蓋 POSIX 權限，以防止該文件系統上的任何文件被執行。

這可以通過執行mount列出所有已掛載的文件系統來檢查；掛載選項列在與文件系統對應的條目中的括號中，例如

/dev/sda3 on /tmp type ext3 (rw,noexec)

您可以將腳本移動到另一個已掛載的文件系統或重新掛載文件系統以允許執行：

sudo mount -o remount,exec /dev/sda3 /tmp

注意：我在/tmp這裡用作範例，因為保持安裝選項集有很好的安全原因。/tmp``noexec,nodev,nosuid

引用自：https://unix.stackexchange.com/questions/203371