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, поэтому они, похоже, мало помогают.

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

Ответы

Ответ 1

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

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

Ответ 2

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

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

# getenforce

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

# setenforce Permissive

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

# chcon -Rt httpd_sys_content_t /path/to/www

Подробнее см. мой здесь.

Ответ 3

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

в nginx.conf

worker_processes 4;
user username;

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

Ответ 4

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

restorecon -r /var/www/html

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

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

sudo setfacl -b /home/foo/bar

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

Ответ 8

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

usermod -aG psacln nginx

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

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

usermod -aG psaserv apache

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

Ответ 9

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

index index.php index.html;

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

Ответ 10

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

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

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

Ответ 11

Эта ошибка не имеет ничего общего с разрешением папок в вашем файловом менеджере, на самом деле это разрешение требуется из файлов конфигурации nginx. Я решил ту же проблему с сервером Apache.

Вот решение для ошибок разрешения файлов в Nginx

Ответ 12

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

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

sudo setenforce 0

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