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

Question

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

Nginx работает как www-data: www-data, и сайт по умолчанию «Welcome to 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-данных с правами доступа 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"

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

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

Answer 1

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

РЕДАКТИРОВАТЬ: Чтобы легко отобразить все разрешения для пути, вы можете использовать namei -om /path/to/check

Answer 2

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

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

# getenforce

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

# setenforce Permissive

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

# chcon -Rt httpd_sys_content_t /path/to/www

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

Answer 3

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

в nginx.conf

worker_processes 4;
user username;

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

Answer 4

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

restorecon -r /var/www/html

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

Если вы используете SELinux, просто наберите:

sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/

Это решит проблему с разрешениями.

Answer 8

Я столкнулся с той же проблемой, но вышеуказанные решения не помогли.

Итак, после большой борьбы я обнаружил, что sestatus был настроен на принудительное выполнение, блокирующее все порты, и установив его как разрешающий все проблемы были решены.

sudo setenforce 0

Надеюсь, это поможет кому-то вроде меня.

Answer 9

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

index index.php index.html;

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

Answer 10

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

usermod -aG psacln nginx

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

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

usermod -aG psaserv apache

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