Nginx 403 запрещено для всех файлов
у меня установлен nginx с PHP - FPM на коробке CentOS 5, но я изо всех сил пытаюсь заставить его обслуживать любой из моих файлов-будь то PHP или нет.
Nginx работает как www-data: www-data, и сайт по умолчанию "Добро пожаловать в nginx на EPEL" (принадлежит root:root с разрешениями 644) загружается нормально.
файл конфигурации nginx имеет директиву include для /etc/nginx/sites-включено/*.conf, и у меня есть файл конфигурации пример.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, поэтому они, похоже, имеют мало помощь.
Я сделал что-то глупое здесь?
9 ответов
одно требование разрешения, которое часто упускается из виду, - это X разрешений в каждом родительском каталоге файла для доступа к этому файлу. Проверьте разрешения на /, / home, / home / demo и т. д. для www-data x access. Я предполагаю, что /home, вероятно, 770 и www-data не могут chdir через него добраться до любого субдира. Если это так, попробуйте chmod o+x / home (или любой другой dir отрицает запрос).
EDIT: чтобы легко отобразить все разрешения на пути, вы можете использовать namei -om /path/to/check
если вы все еще видите permission denied
после проверки разрешений родительских папок это может быть настройки SELinux ограничение доступа.
чтобы проверить, работает ли SELinux:
# getenforce
чтобы отключить SELinux до следующей перезагрузки:
# setenforce Permissive
перезапустите Nginx и посмотрите, сохраняется ли проблема. Чтобы разрешить nginx обслуживать ваш каталог www (убедитесь, что вы снова включили SELinux перед тестированием. я.е setenforce Enforcing
)
# chcon -Rt httpd_sys_content_t /path/to/www
посмотреть мои ответ вот!--17--> дополнительные детали
Я решил эту проблему, добавив пользовательские настройки.
в nginx.conf
worker_processes 4;
user username
измените "имя пользователя" с именем пользователя linux.
У меня есть эта ошибка, и я, наконец, решил ее с помощью команды ниже.
restorecon -r /var/www/html
проблема возникает, когда вы МВ что-то из одного места в другое. Он сохраняет контекст selinux оригинала при его перемещении, поэтому, если вы распаковываете что-то в /home или /tmp, он получает контекст selinux, который соответствует его местоположению. Теперь вы mv, что к /var / www / html, и он берет контекст, говоря, что он принадлежит в /tmp или / home с ним, и httpd не разрешен политикой для доступа к ним файлы.
Если вы обрабатываете файлы вместо mv, контекст selinux назначается в соответствии с местоположением, в которое вы копируете, а не откуда он исходит. Запуск restorecon возвращает контекст по умолчанию и исправляет его.
Я пробовал разные случаи и только когда владелец был установлен в nginx (chown -R nginx:nginx "/var/www/myfolder"
) - Он начал работать, как ожидалось.
старый вопрос, но у меня была та же проблема. Я пробовал каждый ответ выше, ничего не получилось. Что исправило это для меня, хотя удаляло домен и добавляло его снова. Я использую Plesk, и я установил Nginx после того, как домен уже был там.
сначала сделал локальную резервную копию в /var/www / Backup. Чтобы я мог легко скопировать файлы.
странная проблема....
я зарылся в небольшой вариант этой проблемы, ошибочно запустив . Я побежал:
sudo setfacl -m user:nginx:r /home/foo/bar
я отказался от этого маршрута в пользу добавления nginx
до foo
group, но этот пользовательский 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)
Если вы используете PHP, убедитесь, что index
директива NGINX в блоке сервера содержит индекс.на PHP:
index index.php index.html;
для получения дополнительной информации заказ директива Index в официальной документации.