Nginx 403 zabroniony dla wszystkich plików

Mam nginx zainstalowany z PHP-FPM na pudełku CentOS 5, ale staram się, aby obsłużył którykolwiek z moich plików - czy to PHP, czy nie.

Nginx działa jako www-data: www-data, a domyślna strona „Witamy w nginx na EPEL” (własność root: root z uprawnieniami 644) ładuje się dobrze.

Plik konfiguracyjny nginx ma dyrektywę dołączającą dla /etc/nginx/sites-enabled/*.conf, a ja mam plik konfiguracyjny example.com.conf , a zatem:

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;
 }
}

Mimo że public_html jest własnością www-data: www-data z uprawnieniami do pliku 2777, ta strona nie wyświetla żadnych treści -

 [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"

Znalazłem wiele innych postów, w których użytkownicy otrzymywali 403s od nginx, ale większość, które widziałem, dotyczyło albo bardziej złożonych konfiguracji z Ruby / Passenger (z którymi tak naprawdę się kiedyś udało) lub otrzymywało błędy tylko wtedy, gdy upstream PHP -FPM jest zaangażowany, więc wydają się mało pomocne.

Czy zrobiłem tu coś głupiego?

Jednym z często pomijanych wymagań dotyczących uprawnień jest to, że użytkownik potrzebuje x uprawnień w każdym katalogu nadrzędnym pliku, aby uzyskać dostęp do tego pliku. Sprawdź uprawnienia do /, / home, / home / demo itp., Aby uzyskać dostęp do danych www x. Domyślam się, że / home to prawdopodobnie 770 i www-data nie może przechodzić przez to, by dostać się do dowolnego podkatalogu. Jeśli tak, spróbuj chmod o + x / home (lub cokolwiek dir odrzuca żądanie).

EDYCJA: Aby łatwo wyświetlić wszystkie uprawnienia na ścieżce, możesz użyć namei -om /path/to/check

Jeśli nadal widzisz permission deniedpo sprawdzeniu uprawnień do folderów nadrzędnych, może to oznaczać, że SELinux ogranicza dostęp.

Aby sprawdzić, czy SELinux działa:

# getenforce

Aby wyłączyć SELinux do następnego uruchomienia:

# setenforce Permissive

Uruchom ponownie Nginx i sprawdź, czy problem nadal występuje. Aby zezwolić nginx na obsługę twojego katalogu www (pamiętaj, aby ponownie włączyć SELinux przed przetestowaniem tego. Np. setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

Zobacz moją odpowiedź tutaj, aby uzyskać więcej informacji

Rozwiązałem ten problem, dodając ustawienia użytkownika.

w nginx.conf

worker_processes 4;
user username;

zmień „nazwę użytkownika” na nazwę użytkownika linux.

Mam ten błąd i w końcu rozwiązałem go za pomocą poniższego polecenia.

restorecon -r /var/www/html

Problem występuje, gdy przenosisz coś z jednego miejsca do drugiego. Zachowuje kontekst selinux oryginału podczas jego przenoszenia, więc jeśli rozpakowujesz coś w / home lub / tmp, dostaje kontekst selinux, który pasuje do jego położenia. Teraz możesz to zrobić do / var / www / html i bierze kontekst, mówiąc, że należy do niego w / tmp lub / home, a zasady httpd nie zezwalają na dostęp do tych plików.

Jeśli cp pliki zamiast mv, kontekst selinux zostanie przypisany zgodnie z lokalizacją, do której kopiujesz, a nie skąd pochodzi. Uruchomienie restorecon przywraca domyślny kontekst i naprawia go.

Próbowałem różnych przypadków i tylko wtedy, gdy właściciel ustawiono na nginx ( chown -R nginx:nginx "/var/www/myfolder") - zaczął działać zgodnie z oczekiwaniami.

Jeśli używasz SELinux, po prostu wpisz:

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

To naprawi problem z uprawnieniami.

Stare pytanie, ale miałem ten sam problem. Próbowałem wszystkich odpowiedzi powyżej, nic nie działało. Jednak naprawiłem to, usuwając domenę i dodając ją ponownie. Korzystam z Plesk i zainstalowałem Nginx PO, gdy domena już tam była.

Najpierw jednak zrobiłem lokalną kopię zapasową w / var / www / backups. Więc mogłem łatwo skopiować pliki.

Dziwny problem ....

Mieliśmy ten sam problem, używając Plesk Onyx 17. Zamiast mieszać się z prawami itp. Rozwiązaniem było dodanie użytkownika nginx do grupy psacln, w której wszyscy inni właściciele domen (użytkownicy) to:

usermod -aG psacln nginx

Teraz nginx ma prawa dostępu do pliku .htaccess lub dowolnego innego pliku niezbędnego do prawidłowego wyświetlenia treści.

Z drugiej strony upewnij się również, że Apache jest w grupie psaserv, aby obsługiwać zawartość statyczną:

usermod -aG psaserv apache

Nie zapomnij zrestartować Apache i Nginx w Plesku po! (i przeładuj strony za pomocą Ctrl-F5)

Zagłębiłem się w niewielkim wariancie tego problemu, błędnie uruchamiając setfaclpolecenie. Prowadziłem:

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

Porzuciłem tę trasę na rzecz dodania nginxdo foogrupy, ale ta niestandardowa lista ACL udaremnia próby uzyskania dostępu do pliku przez nginx. Wyczyściłem to, uruchamiając:

sudo setfacl -b /home/foo/bar

I wtedy nginx mógł uzyskać dostęp do plików.

Jeśli używasz PHP, upewnij się, że indexdyrektywa NGINX w bloku serwera zawiera plik index.php:

index index.php index.html;

Aby uzyskać więcej informacji, sprawdź dyrektywę indeksową w oficjalnej dokumentacji.

Miałem do czynienia z tym samym problemem, ale powyższe rozwiązania nie pomogły.

Tak więc po wielu zmaganiach dowiedziałem się, że sestatus został ustawiony, aby wymusić blokowanie wszystkich portów, a ustawiając go na permisive, wszystkie problemy zostały rozwiązane.

sudo setenforce 0

Mam nadzieję, że to pomaga komuś jak ja.