Nginx 403 vietato per tutti i file

Ho installato nginx con PHP-FPM su un box CentOS 5, ma sto lottando per farlo funzionare su uno qualsiasi dei miei file, che sia PHP o meno.

Nginx funziona come www-data: www-data e il sito predefinito "Benvenuto in nginx su EPEL" (di proprietà di root: root con permessi 644) viene caricato correttamente.

Il file di configurazione nginx ha una direttiva include per /etc/nginx/sites-enabled/*.conf e ho un file di configurazione example.com.conf , quindi:

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

Nonostante public_html sia di proprietà di www-data: www-data con permessi sui file 2777, questo sito non riesce a pubblicare alcun contenuto -

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

Ho trovato numerosi altri post con utenti che ottengono 403 da nginx, ma la maggior parte di quelli che ho visto coinvolgono configurazioni più complesse con Ruby / Passenger (che in passato ci sono riuscito) o stanno ricevendo errori solo quando il PHP a monte -FPM è coinvolto, quindi sembrano essere di scarso aiuto.

Ho fatto qualcosa di stupido qui?

Un requisito di autorizzazione che viene spesso trascurato è che un utente ha bisogno di autorizzazioni x in ogni directory principale di un file per accedere a quel file. Controlla le autorizzazioni su /, / home, / home / demo, ecc. Per l'accesso a www-data x. La mia ipotesi è che / home sia probabilmente 770 e www-data non riesca a controllarlo per arrivare a nessun subdir. Se lo è, prova chmod o + x / home (o qualunque altra directory stia negando la richiesta).

MODIFICA: per visualizzare facilmente tutte le autorizzazioni su un percorso, è possibile utilizzare namei -om /path/to/check

Se vedi ancora permission denieddopo aver verificato le autorizzazioni delle cartelle principali, potrebbe essere SELinux a limitare l'accesso.

Per verificare se SELinux è in esecuzione:

# getenforce

Per disabilitare SELinux fino al prossimo riavvio:

# setenforce Permissive

Riavvia Nginx e verifica se il problema persiste. Per consentire a nginx di servire la tua directory www (assicurati di riaccendere SELinux prima di provare questo. Cioè, setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

Vedi la mia risposta qui per maggiori dettagli

Ho risolto questo problema aggiungendo le impostazioni dell'utente.

in nginx.conf

worker_processes 4;
user username;

cambia il 'nome utente' con il nome utente linux.

Ho questo errore e finalmente l'ho risolto con il comando seguente.

restorecon -r /var/www/html

Il problema è causato quando mv qualcosa da un posto all'altro. Conserva il contesto selinux dell'originale quando lo sposti, quindi se annulli qualcosa in / home o / tmp gli viene dato un contesto selinux che corrisponde alla sua posizione. Ora lo mvate in / var / www / html e ci vuole il contesto dicendo che appartiene a / tmp o / home con esso e httpd non è autorizzato dalla politica ad accedere a quei file.

Se copi i file invece di mv, il contesto selinux viene assegnato in base alla posizione in cui stai copiando, non da dove proviene. L'esecuzione di restorecon riporta il contesto al suo valore predefinito e lo risolve anche.

Ho provato diversi casi e solo quando il proprietario era impostato su nginx ( chown -R nginx:nginx "/var/www/myfolder") - ha iniziato a funzionare come previsto.

Se stai usando SELinux, digita:

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

Ciò risolverà il problema di autorizzazione.

Vecchia domanda, ma ho avuto lo stesso problema. Ho provato tutte le risposte sopra, niente ha funzionato. Ciò che lo ha risolto per me è stato la rimozione del dominio e l'aggiunta di nuovo. Sto usando Plesk e ho installato Nginx DOPO che il dominio era già lì.

Prima ho fatto un backup locale su / var / www / backups. Quindi potrei facilmente copiare indietro i file.

Strano problema ....

Abbiamo avuto lo stesso problema, usando Plesk Onyx 17. Invece di sbagliare con i diritti ecc., La soluzione era quella di aggiungere l'utente nginx nel gruppo psacln, in cui tutti gli altri proprietari di dominio (utenti) erano:

usermod -aG psacln nginx

Ora nginx ha i diritti per accedere a .htaccess o qualsiasi altro file necessario per mostrare correttamente il contenuto.

D'altra parte, assicurati anche che Apache sia nel gruppo psaserv, per servire contenuto statico:

usermod -aG psaserv apache

E non dimenticare di riavviare sia Apache che Nginx in Plesk dopo! (e ricarica le pagine con Ctrl-F5)

Mi sono scavato in una leggera variante di questo problema eseguendo erroneamente il setfaclcomando. Ho corso:

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

Ho abbandonato questa strada in favore dell'aggiunta nginxal foogruppo, ma quell'ACL personalizzato stava ostacolando i tentativi di nginx di accedere al file. L'ho cancellato eseguendo:

sudo setfacl -b /home/foo/bar

E poi nginx è stato in grado di accedere ai file.

Se stai usando PHP, assicurati che la indexdirettiva NGINX nel blocco server contenga un index.php:

index index.php index.html;

Per maggiori informazioni, consulta la direttiva sugli indici nella documentazione ufficiale.

Stavo affrontando lo stesso problema ma le soluzioni di cui sopra non mi hanno aiutato.

Quindi, dopo molte lotte, ho scoperto che sestatus era impostato per far rispettare che bloccava tutte le porte e impostandolo su permissivo tutte le questioni sono state risolte.

sudo setenforce 0

Spero che questo aiuti qualcuno come me.