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, и у меня есть конфигурационный файл пример.ком.конф, таким образом:

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, поэтому они кажутся небольшими помощь.

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

9 162
nginx php centos http-status-code-403

9 ответов:

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

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

294

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

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

# getenforce

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

# setenforce Permissive

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

# chcon -Rt httpd_sys_content_t /path/to/www

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

247

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

в nginx.conf

worker_processes 4;
user username

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

45

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

restorecon -r /var/www/html

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

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

22

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

19

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

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

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

1

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

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

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

sudo setfacl -b /home/foo/bar

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

0

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

usermod -aG psacln nginx

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

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

usermod -aG psaserv apache

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

0

Если вы используете PHP, убедитесь, что index директива NGINX в блоке сервера содержит индекс.php:

index index.php index.html;

для получения дополнительной информации заказ директива Index в официальной документации.

0