Nginx 403 запрещен для всех файлов

Одно требование о разрешении, которое часто упускается из виду, – это то, что пользователю необходимы разрешения x в каждом родительском каталоге файла для доступа к этому файлу. Проверьте разрешения на /, / home, / home / demo и т. Д. Для доступа к www-data x. Я предполагаю, что / home, вероятно, 770, а www-data не может chdir через него, чтобы добраться до любого субдира. Если это так, попробуйте chmod o + x / home (или любой другой каталог, запрещающий запрос).

EDIT: Чтобы легко отобразить все разрешения на пути, вы можете использовать namei -om /path/to/check

Если вы все еще видите, что permission denied после проверки прав родительских папок, это может быть ограничение доступа SELinux .

Чтобы проверить, работает ли SELinux:

 # getenforce 

Чтобы отключить SELinux до следующей перезагрузки:

 # setenforce Permissive 

Перезапустите Nginx и проверьте, не исчезла ли проблема. Чтобы позволить nginx обслуживать ваш каталог www (убедитесь, что вы снова setenforce Enforcing SELinux, прежде чем тестировать это, то есть setenforce Enforcing )

 # chcon -Rt httpd_sys_content_t /path/to/www 

См. Мой ответ здесь для получения более подробной информации.

Я решил эту проблему, добавив пользовательские настройки.

в nginx.conf

 worker_processes 4; user username 

измените имя пользователя с именем пользователя linux.

Я пробовал разные случаи и только когда владелец был настроен на nginx ( chown -R nginx:nginx "/var/www/myfolder" ) – он начал работать, как ожидалось.

У меня есть эта ошибка, и я, наконец, решил ее с помощью приведенной ниже команды.

 restorecon -r /var/www/html 

Проблема возникает, когда вы mv что-то из одного места в другое. Он сохраняет контекст selinux оригинала, когда вы его перемещаете, поэтому, если вы разворачиваете что-то в / home или / tmp, ему присваивается контекст selinux, который соответствует его местоположению. Теперь вы mv, чтобы / var / www / html, и он принимает контекст, говорящий, что он принадлежит / tmp или / home с ним, а httpd не разрешено политикой для доступа к этим файлам.

Если вы используете файлы вместо mv, то контекст selinux присваивается в соответствии с местоположением, в котором вы копируете, а не там, откуда оно происходит. Запуск restorecon возвращает исходный контекст и исправляет его.

Старый вопрос, но у меня была такая же проблема. Я пробовал каждый ответ выше, ничего не работало. Я исправил это для меня, хотя удалял домен и добавлял его снова. Я использую Plesk, и я установил Nginx ПОСЛЕ того, что домен уже был там.

Однако была локальная резервная копия в / var / www / backups. Поэтому я мог бы легко скопировать файлы.

Странная проблема ….

Я выкопал себя в небольшой вариант по этой проблеме, ошибочно выполнив команду setfacl . Я побежал:

 sudo setfacl -m user:nginx:r /home/foo/bar 

Я отказался от этого маршрута в пользу добавления nginx в группу foo , но этот пользовательский ACL нарушал попытки nginx получить доступ к файлу. Я очистил его, запустив:

 sudo setfacl -b /home/foo/bar 

И тогда nginx смог получить доступ к файлам.

У нас была та же проблема, используя Plesk Onyx 17. Вместо того, чтобы испортить права и т. Д., Решение заключалось в том, чтобы добавить пользователя nginx в группу psacln, в которой были все остальные владельцы (пользователи) домена:

 usermod -aG psacln nginx 

Теперь nginx имеет права доступа .htaccess или любого другого файла, необходимого для правильного отображения содержимого.

С другой стороны, также убедитесь, что Apache находится в группе psaserv, чтобы обслуживать статический контент:

 usermod -aG psaserv apache 

И не забудьте перезапустить как Apache, так и Nginx в Plesk после! (и перезагружать страницы с помощью Ctrl-F5)