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

У меня есть nginx, установленный с PHP-FPM в окне CentOS 5, но я стараюсь заставить его обслуживать любые мои файлы – будь то PHP или нет.

Nginx работает как www-data: www-data, а по умолчанию «Добро пожаловать на сайт nginx на EPEL» (принадлежит root: root с разрешениями 644) загружается отлично.

В файле конфигурации nginx есть директива include для /etc/nginx/sites-enabled/*.conf, и у меня есть файл конфигурации example.com.conf , таким образом:

server { listen 80; Virtual Host Name server_name www.example.com example.com; location / { root /home/demo/sites/example.com/public_html; index index.php index.htm index.html; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_param SCRIPT_FILENAME /home/demo/sites/example.com/public_html$fastcgi_script_name; include fastcgi_params; } } 

Несмотря на то, что public_html принадлежит www-data: www-data с 2777 правами доступа к файлам, этот сайт не может обслуживать какой-либо контент –

  [error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com" 

Я нашел множество других сообщений с пользователями, получающими 403s от nginx, но большинство из того, что я видел, связано либо с более сложными настройками с Ruby / Passenger (которые в прошлом я на самом деле преуспел), либо получаю ошибки только при восходящем PHP -FPM, поэтому они, похоже, мало помогают.

Я сделал здесь что-то глупое?

Solutions Collecting From Web of "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)