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

192

У меня 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-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"

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

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

Ангус Ирландия
источник
проверить этот ответ stackoverflow.com/questions/16808813/...
Sandes

Ответы:

334

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

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

kolbyjack
источник
6
Тоже самое. В моей установке CentOS 6 для / home / user dirs по умолчанию установлено значение 700.
JJT
2
Этот парень тоже говорит об этом: ( chmod -4 +x /mypathработал для меня) nginxlibrary.com/403-forbidden-error
Питер Эрлих
1
Может кто-нибудь объяснить, почему это поведение отличается от apache, который НЕ требует, чтобы у каждого родительского каталога были разрешения "x"?!?
Джошуа Дэвид
3
Это не отличается. Единственная причина, по которой apache не требует разрешения x для родительских каталогов, заключается в том, что он работает от имени пользователя root.
kolbyjack
В итоге я добавил пользователя www-data в свою личную группу пользователей и выполнил команду chmod 710 в моей корневой папке пользователя. Работал как шарм. (На дистрибутиве на основе Debian)
basicdays
299

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

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

# getenforce

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

# setenforce Permissive

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

# chcon -Rt httpd_sys_content_t /path/to/www

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

Kurt
источник
1
Я не мог понять, почему всякий раз, когда я запускал nginx, он говорил open() "/usr/share/nginx/logs/xxxxxx.com-error_log" failed (13: Permission denied)после того, как проверил разрешения и убедился, что он запускается как root. Я столкнулся с этим и узнал, что SELinux был включен. Я отключил его, и теперь он работает без проблем. Спасибо!
ub3rst4r
1
Спасибо! Я все еще была проблема с разрешения запрещен для пользователей , владеющих своими FPM сокетов , так что я был в состоянии установить , что один, изменяя userот Nginx к корню в /var/nginx/nginx.conf- возможно, поможет кому -то еще , кто приходит через этот вопрос. S / O для DataPsyche для второй части.
зима
11
Это поведение по умолчанию в CentOS 7, а также.
Timss
4
Я со всеми, кто прокомментировал. Я был готов выбросить мой компьютер в окно. Nginx был настроен правильно, права доступа были установлены правильно, я даже зашел так далеко, чтобы все было 777, и все равно получил ошибку «Отказано в разрешениях».
Официальный
2
На Centos 7 (SELinux включен) самым простым исправлением для меня было setsebool httpd_read_user_content on(для статических файлов, размещенных из домашнего каталога, chmod'ed для чтения в любой точке мира) - хотя я думаю, что описанный выше метод @ KapiteinWitbaard более безопасен.
TimStaley
63

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

в nginx.conf

worker_processes 4;
user username;

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

Андерсон
источник
4
Я считаю, что этот ответ лучше с точки зрения безопасности, чем принятый ответ. Вам не нужно возиться с разрешениями в вашей домашней папке (которая может содержать конфиденциальную информацию), и если вы занимаетесь разработкой с помощью nginx, это избавляет вас от необходимости загружать странные разрешения на файлы в SCM.
CamelBlues
Добавленные разрешения для домашнего каталога выполняются, а не читаются, поэтому конфиденциальная информация (теоретически) не раскрывается (за исключением, в этом случае, возможно, вредоносного сценария PHP, который рекурсивно поднимается и знает местоположение конфиденциальных файлов в другом каталоге). доступно для www-данных). Вы также заметите, что в исходном вопросе мой nginx работал как «www-data» - значения конфигурации здесь уже были установлены по желанию.
Ангус Ирландия
2
Пришлось также добавить группу пользователей: user usegroup.
Габриэль А. Зоррилья
У меня тоже сработало (так же, как chmodding dir для nginx: nginx). Однако я предпочитаю это решение, чтобы мой корень документа принадлежал другому пользователю, чем nginx. Спасибо Андерсон за указание на это.
kvdv
спас мой день кстати, что, если на машине есть несколько пользователей, и у каждого пользователя есть свой веб-сайт, как мне с этим справиться?
psychok7 10.09.16
38

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

restorecon -r /var/www/html

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

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

jsina
источник
1
Спасибо @jsina, это мне очень помогло
Pankaj Garg
1
Блин, №1 , я тоже.
jww
24

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

Андрон
источник
1
У меня тоже сработало. Я подозреваю, что это происходит потому, что хотя nginx запускается от имени пользователя root, он порождает процессы под пользователем, указанным в файле nginx.conf, который называется «user nginx;» по умолчанию. Изменение пользователя на пользователя, которому принадлежит ваш корневой каталог документов, также должно работать, как предложил Андерсон.
kvdv
Мистер Андерсон? Нет! Андрон;)
Андрон
Извинения, мистер Андрон;) Я не могу больше редактировать предыдущий комментарий, хотя ...
kvdv
Да не вопрос. Теперь я был как Андерсон :) и мне нужно написать несколько сказок ...
Андрон
1
Разве это не проблема безопасности?
Gontard
6

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

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

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

Дэвид Дин
источник
1

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

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

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

Дэвид
источник
1

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

usermod -aG psacln nginx

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

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

usermod -aG psaserv apache

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

Славомир Мисковец
источник
Это правильный ответ, и он наиболее вероятен usermod -aG username www-dataв большинстве случаев.
Дарио Задро
0

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

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

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

sudo setfacl -b /home/foo/bar

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

danvk
источник
0

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

index index.php index.html;

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

Франциско Занатта
источник
0

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

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

sudo setenforce 0

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

Харви
источник
Хотя это могло бы решить твою проблему - поздравляю! - это немного грустно :-( Смотрите stopdisablingselinux.com - не могли бы вы найти другой обходной путь?
Ангус Ирландия