Запустите ./script.sh против 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. Во многих случаях вы можете просто запустить source script.shили . script.shзапустить команды сценария в текущей интерактивной оболочке. Возможно, вы захотите запустить новый процесс Bash, если скрипт изменяет текущий каталог или иным образом изменяет среду текущего процесса.

Списки контроля доступа

Если биты разрешения POSIX установлены правильно, возможно, был настроен список контроля доступа (ACL), чтобы предотвратить выполнение файла вами или вашей группой. Например, разрешения POSIX могут указывать на то, что сценарий тестовой оболочки является исполняемым.

$ 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имеет разрешения на выполнение, отозванные ограничением ACL 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
• Использование ACL с Fedora Core 2

Файловая система смонтирована с опцией 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набора параметров.

Пытаться

chmod 755 script.sh

это сделает файл исполняемым. Тогда попробуй,

./script.sh

Надеюсь, это сработает.

На моем win7 с админом работает cmd; У меня есть файлы .sh, связанные с cygwin64 / bin / bash, но они были заблокированы cmd. Ни одно из приведенных выше предложений не помогло (chmod, setfacl, mount).

Решение, приведенное ниже, сработало: это acl-fixer кувалды администратора всякий раз, когда папки / файлы становятся недоступными для администратора на win7, что часто бывает):

  Start > run cmd as Admin
  c:\> script.sh
    Access is denied.

  cmd> chmod 0777 script.sh c:\cygwin64\bin\bash.exe
  cmd> script.sh
    Access is denied.

  > assoc .sh
  .sh=bash

  > ftype bash
  bash=C:\cygwin64\bin\bash.exe -- "%1" %*

  > bash
  $ FILE=c:/cygwin64/bin/bash.exe
  $ FILE=${FILE////\\} # s,/,\,g

  # Compare these permissions using accesschk by Mark Russinovich 2015
  $ accesschk.exe -lq  $FILE 
  $ accesschk.exe -lq c:/windows/system32/cmd.exe
  # [large output not shown]

  # === Solution: Change windows acl for bash ===
  $ takeown /F $FILE /A > /dev/null
  $ icacls $FILE /t /q /c /reset
  $ icacls $FILE /t /q /c /grant    :r Everyone:F
  $ icacls $FILE /t /q /c /setowner Administrators  
  # ====

  cmd> script.sh
    OK .. invokes bash