Nginx: stat () не вдалося (13: дозвіл відхилено)

Я використовую конфігурацію за замовчуванням під час додавання конкретного каталогу з nginx, встановленим на моїй машині ubuntu 12.04.

server {
        #listen   80; ## listen for ipv4; this line is default and implied
        #listen   [::]:80 default ipv6only=on; ## listen for ipv6

        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name localhost;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to index.html
                root /username/test/static;
                try_files $uri $uri/ /index.html;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
        }
...

...
}

Я просто хочу простий статичний сервер nginx для обслуговування файлів із цього каталогу. Однак перевірка error.logбачу

2014/09/10 16:55:16 [crit] 10808#0: *2 stat() "/username/test/static/index.html" failed (13: Permission denied), client:, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "domain"
2014/09/10 16:55:16 [error] 10808#0: *2 rewrite or internal redirection cycle while internally redirecting to "/index.html

Я вже зробив chown -R www-data:www-dataна /username/test/static, я поставив їх chmod 755. Я не знаю, що ще потрібно встановити.

Nginx працює в каталозі, тому, якщо ви не можете cdдо цього каталогу від користувача nginx, він вийде з ладу (як і statкоманда у вашому журналі). Переконайтеся, що www-userможна cdдо кінця /username/test/static. Ви можете підтвердити, що statзапуск буде невдалим або успішним, запустивши

sudo -u www-data stat /username/test/static

У вашому випадку, ймовірно, /usernameтут проблема. Зазвичай www-dataне має дозволів на cdвикористання інших домашніх каталогів інших користувачів.

Найкращим рішенням у цьому випадку буде додавання www-dataдо usernameгрупи:

gpasswd -a www-data username

і переконайтеся, що usernameгрупа може входити до всіх каталогів по шляху:

chmod g+x /username && chmod g+x /username/test && chmod g+x /username/test/static

Щоб ваші зміни працювали, перезавантажте nginx

nginx -s reload

У мене якраз була та сама проблема у вікні CentOS 7.

Здається, я потрапив у selinux. Переведення selinux в дозвільний режим ( setenforce permissive) наразі вирішило проблему. Я спробую повернутися з правильним виправленням.

Nginx повинен мати + x доступ до всіх каталогів, що ведуть до кореневого каталогу сайту.

Переконайтеся, що у вас є + x у всіх каталогах на шляху, що веде до кореня сайту. Наприклад, якщо корінь сайту є / home / username / siteroot:

chmod +x /home/
chmod +x /home/username
chmod +x /home/username/siteroot

У CentOS 7.0 у мене була Access Deinedпроблема, викликана SELinux, і ці кроки вирішили проблему:

yum install -y policycoreutils-devel
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp

Оновлення: лише побічна примітка до того, що я дізнався, використовуючи віртуальні сервери Linux digitalocean, або як вони їх називають Краплі . Для використання SELinux потрібен пристойний об'єм оперативної пам'яті. Це, мабуть, так, що ви не зможете запустити та керувати SELinux на краплі з менш ніж 2 Гб оперативної пам’яті.

Можливо, у вас працює Linux-Enhanced Linux, тому додайте для цього правило. Я мав дозвіл 13 помилок, навіть незважаючи на те, що дозволи були встановлені та користувач існував.

chcon -Rt httpd_sys_content_t /username/test/static

Симптом:

Не вдалося завантажити зображення в медіатеку WordPress.

Причина:

(CentOS) yum update

Помилка:

2014/10/22 18:08:50 [crit] 23286#0: *5332 open() "/var/lib/nginx/tmp/client_body/0000000003" failed (13: Permission denied), client: 1.2.3.4, server: _, request: "POST /wp-admin/media-new.php HTTP/1.1", host: "example.com", referrer: "http://example/wp-admin/media-new.php"

Рішення:

chown -R www-data:www-data /var/lib/nginx

За замовчуванням статичні дані при встановленні nginx будуть в / var / www / html. Таким чином, ви можете просто скопіювати свою статичну папку в / var / html / і встановити

root /var/www/<your static folder>

в ngix.conf (або / etc / nginx / sites-available / default)

Це працювало для мене на ubuntu, але, мабуть, воно не повинно сильно відрізнятися для інших дистрибутивів.

Сподіваюся, це допомагає.

Змініть nginx.conf userвласність на www-staticвласників файлів.

#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user your_user_name;

# same other config

Я зіткнувся з цією проблемою, і вирішив її, щоб дати дозволи користувачу nginx та групувати щось подібне:

chown -R nginx:nginx /username/test/static

У моєму випадку папка, яка обслуговувала файли, була символічним посиланням на іншу папку, зроблену за допомогою

ln -sf /origin /var/www/destination

Навіть незважаючи на те, що дозволи (користувачі та групи), де правильно в папці призначення (символічне посилання), у мене все-таки була помилка, оскільки Nginx також потребував дозволів до цілої ієрархії вихідної папки.

Я нарешті знайшов шлях. Якщо коротко, скажімо, ваше ім’я користувача є, joeі ви розміщуєте веб-сайт під своєю особистою файловою системою /home/joe/path/to/website.

Ви буквально повинні сказати системі, яка nginxє вашим товаришем.
Місце nginxу joeгрупі:

sudo gpasswd -a nginx joe

Після цього, якщо вона все ще не працює, перевірте правий доступ до /home/joeкаталогу. Це, мабуть, причина, чому nginx не може дістатися до файлу, тому що навіть якщо він є вашим другом, вам доведеться відкрити йому двері до вашого будинку:

sudo chmod g+x /home/joe

Це воно. Це буквально все, що вам потрібно зробити, щоб надати nginx доступ до ваших локальних файлів :)

Я не думаю, що з цим методом nginxє проблеми з безпекою, оскільки це високий авторитет і лише адміністратор може змінити групу. nginxтепер може читати те, що знаходиться в joeкаталогах. Це лише порушення безпеки, якщо власник nginxоблікового запису відрізняється від користувача, до якого відкривається доступ до каталогу, але в моєму випадку я є власником обох сторін, тобто в локальному контексті.

У мене була така ж проблема, я використовую Plesk Onyx 17 з Centos7. Я можу бачити цю помилку в proxy_error_log під журналами домену. Усі файли в / var / www / vhosts / належать відповідним користувачам (власникам доменів), і ви можете бачити, що всі вони входять у групу psacln. Тому рішенням було додати nginx також до цієї групи, щоб він міг бачити, що йому потрібно:

usermod -aG psacln nginx

І дійсно, перезавантажте nginx та перезавантажте сторінку за допомогою Ctrl + F5.

Я знайшов роботу: перемістив папку в папку конфігурації nginx, в моєму випадку "/ etc / nginx / my-web-app". А потім змінив дозволи на root користувача "sudo chown -R root: root" my-web-app ".

Ви також можете додати, який користувач буде запускати nginx. У файлі nginx.conf внесіть такі зміни:

user root;

Ви можете додати вищезазначений рядок як перший рядок у вашій nginx конф. Ви можете написати ім'я будь-якого користувача, який має дозвіл на запис у цей каталог.

Зазвичай це проблема привілеїв ... Для мене це те, що я використовую / root / ** як корінь nginx, йому потрібна більш висока привілей. Простий спосіб - просто перенести проект у каталог, створений вами.