У меня 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 участвует, поэтому они, кажется, мало помогают.
Я сделал что-то глупое здесь?
источник
Ответы:
Одно требование разрешения, которое часто пропускается, - пользователю нужны x разрешения в каждом родительском каталоге файла для доступа к этому файлу. Проверьте разрешения на /, / home, / home / demo и т. Д. Для доступа к www-данным x. Я предполагаю, что / home - это, вероятно, 770, и www-данные не могут пройти через него, чтобы добраться до любого подкаталога. Если это так, попробуйте chmod o + x / home (или любой другой каталог, который отклоняет запрос).
РЕДАКТИРОВАТЬ: Чтобы легко отобразить все разрешения на пути, вы можете использовать
namei -om /path/to/check
источник
chmod -4 +x /mypath
работал для меня) nginxlibrary.com/403-forbidden-errorЕсли вы все еще видите
permission denied
после проверки прав доступа родительских папок, возможно, SELinux ограничивает доступ.Чтобы проверить, работает ли SELinux:
Чтобы отключить SELinux до следующей перезагрузки:
Перезапустите Nginx и посмотрите, сохраняется ли проблема. Чтобы позволить nginx обслуживать ваш каталог www (убедитесь, что вы включили SELinux перед тестированием. Т.е.,
setenforce Enforcing
)Смотрите мой ответ здесь для более подробной информации
источник
open() "/usr/share/nginx/logs/xxxxxx.com-error_log" failed (13: Permission denied)
после того, как проверил разрешения и убедился, что он запускается как root. Я столкнулся с этим и узнал, что SELinux был включен. Я отключил его, и теперь он работает без проблем. Спасибо!user
от Nginx к корню в/var/nginx/nginx.conf
- возможно, поможет кому -то еще , кто приходит через этот вопрос. S / O для DataPsyche для второй части.setsebool httpd_read_user_content on
(для статических файлов, размещенных из домашнего каталога, chmod'ed для чтения в любой точке мира) - хотя я думаю, что описанный выше метод @ KapiteinWitbaard более безопасен.Я решил эту проблему, добавив пользовательские настройки.
в nginx.conf
измените имя пользователя с именем пользователя linux.
источник
У меня есть эта ошибка, и я наконец решил ее с помощью команды ниже.
Проблема возникает, когда вы перемещаете что-то из одного места в другое. Он сохраняет контекст selinux оригинала, когда вы перемещаете его, поэтому, если вы распаковываете что-то в / home или / tmp, он получает контекст selinux, который соответствует его местоположению. Теперь вы перемещаете это в / var / www / html, и он принимает контекст, в котором говорится, что он принадлежит к / tmp или / home вместе с ним, и политика httpd не разрешает доступ к этим файлам.
Если вы копируете файлы вместо mv, контекст selinux назначается в соответствии с местом, в которое вы копируете, а не с того, откуда оно берется. Запуск restorecon возвращает контекст по умолчанию и исправляет его.
источник
Я пробовал разные случаи и только когда владелец был установлен в nginx (
chown -R nginx:nginx "/var/www/myfolder"
) - он начал работать как положено.источник
Если вы используете SELinux, просто наберите:
Это решит проблему с разрешениями.
источник
Старый вопрос, но у меня была такая же проблема. Я пробовал каждый ответ выше, ничего не получалось. Что исправило это для меня, хотя было удаление домена и добавление его снова. Я использую Plesk, и я установил Nginx ПОСЛЕ того, как домен уже был там.
Сначала сделал локальное резервное копирование в / var / www / backups. Так что я мог легко скопировать обратно файлы.
Странная проблема ....
источник
У нас была та же проблема, с использованием Plesk Onyx 17. Вместо того, чтобы связываться с правами и т. Д., Было решение добавить пользователя nginx в группу psacln, в которой все остальные владельцы домена (пользователи) были:
Теперь nginx имеет права доступа к .htaccess или любому другому файлу, необходимому для правильного отображения содержимого.
С другой стороны, также убедитесь, что Apache входит в группу psaserv, чтобы обслуживать статический контент:
И не забудьте перезапустить Apache и Nginx в Plesk после этого! (и перезагрузите страницы с помощью Ctrl-F5)
источник
usermod -aG username www-data
в большинстве случаев.Я покопался в небольшом варианте этой проблемы, по ошибке выполнив
setfacl
команду. Я побежал:Я отказался от этого пути в пользу добавления
nginx
вfoo
группу, но этот пользовательский ACL препятствовал попыткам nginx получить доступ к файлу. Я очистил это, запустив:И тогда nginx смог получить доступ к файлам.
источник
Если вы используете PHP, убедитесь, что
index
директива NGINX в блоке сервера содержит index.php:index index.php index.html;
Для получения дополнительной информации ознакомьтесь с директивой index в официальной документации.
источник
Я столкнулся с той же проблемой, но вышеуказанные решения не помогли.
Итак, после большой борьбы я обнаружил, что sestatus был настроен на принудительное выполнение, которое блокирует все порты, и установив его как разрешающий все проблемы, были решены.
Надеюсь, это поможет кому-то вроде меня.
источник