Запустити ./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. У багатьох випадках можна просто запустити 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-закріплювача адміністратора, коли папки / файл стають недоступними для адміністратора на 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