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

У мене встановлено 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"

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

Я тут щось дурне зробив?

Однією з вимог дозволу, яку часто ігнорують, є необхідність користувачу x дозволів у кожному батьківському каталозі файлу для доступу до цього файлу. Перевірте дозволи на /, / home, / home / demo тощо на доступ до www-data x. Я здогадуюсь, що / 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

Дивіться мою відповідь тут для отримання більш детальної інформації

Я вирішив цю проблему, додавши налаштування користувача.

в nginx.conf

worker_processes 4;
user username;

змінити "ім'я користувача" на ім'я користувача linux.

У мене ця помилка, і я нарешті її вирішив за допомогою команди нижче.

restorecon -r /var/www/html

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

Якщо ви cp файли замість mv їх, контекст selinux присвоюється відповідно до місця, в яке ви копіюєте, а не звідки він надходить. Запуск Restocon повертає контекст до свого типового значення і його також виправляє.

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

Якщо ви використовуєте SELinux, просто введіть:

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

Це дозволить вирішити проблему з дозволом.

Старе питання, але у мене було те саме. Я спробував кожну відповідь вище, нічого не вийшло. Що для мене виправлено, це видалення домену та додавання його знову. Я використовую Plesk, і я встановив Nginx ПІСЛЯ домену вже там.

Хоча спочатку зробили локальну резервну копію в / var / www / backup. Тож я міг легко скопіювати назад файли.

Дивна проблема ....

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

usermod -aG psacln nginx

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

З іншого боку, також переконайтесь, що Apache знаходиться в групі psaserv, щоб подавати статичний вміст:

usermod -aG psaserv apache

І не забудьте після цього перезапустити і Apache, і Nginx в Plesk! (і перезавантажте сторінки за допомогою Ctrl-F5)

Я розібрався в незначному варіанті цієї проблеми, помилково виконуючи setfaclкоманду. Я побіг:

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

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

sudo setfacl -b /home/foo/bar

І тоді nginx зміг отримати доступ до файлів.

Якщо ви використовуєте PHP, переконайтеся, що indexдиректива NGINX у блоці сервера містить index.php:

index index.php index.html;

Для отримання додаткової інформації ознайомтеся з директивою щодо індексу в офіційній документації.

Я стикався з тим же питанням, але вищевикладені рішення не допомогли.

Отже, після великої боротьби я з'ясував, що sestatus був налаштований на виконання, який блокує всі порти, і встановивши його для дозволу всіх питань було вирішено.

sudo setenforce 0

Сподіваюся, це допомагає комусь, як я.