Nginx: stat () non riuscito (13: autorizzazione negata)

Sto usando la configurazione predefinita mentre aggiungo la directory specifica con nginx installato sulla mia macchina Ubuntu 12.04.

server {
        #listen   80; ## listen for ipv4; this line is default and implied
        #listen   [::]:80 default ipv6only=on; ## listen for ipv6

        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name localhost;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to index.html
                root /username/test/static;
                try_files $uri $uri/ /index.html;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
        }
...

...
}

Voglio solo un semplice server nginx statico per servire file fuori da quella directory. Tuttavia, controllando il file error.logI see

2014/09/10 16:55:16 [crit] 10808#0: *2 stat() "/username/test/static/index.html" failed (13: Permission denied), client:, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "domain"
2014/09/10 16:55:16 [error] 10808#0: *2 rewrite or internal redirection cycle while internally redirecting to "/index.html

L'ho già fatto chown -R www-data:www-datasu /username/test/static, li ho impostato a chmod 755. Non so cos'altro deve essere impostato.

Nginx opera all'interno della directory, quindi se non puoi accedere cda quella directory dall'utente nginx, fallirà (come fa il statcomando nel tuo log). Assicurati che la www-userlattina cdfino al /username/test/static. Puoi confermare che statfallirà o riuscirà eseguendo

sudo -u www-data stat /username/test/static

Nel tuo caso probabilmente la /usernamedirectory è il problema qui. Di solito www-datanon ha i permessi per le cdhome directory di altri utenti.

La soluzione migliore in quel caso sarebbe aggiungere www-dataal usernamegruppo:

gpasswd -a www-data username

e assicurati che il usernamegruppo possa inserire tutte le directory lungo il percorso:

chmod g+x /username && chmod g+x /username/test && chmod g+x /username/test/static

Affinché le modifiche funzionino, riavvia nginx

nginx -s reload

Ho appena avuto lo stesso problema su una scatola CentOS 7.

Sembra che abbia colpito Selinux. Mettere selinux in modalità permissiva ( setenforce permissive) ha risolto il problema per ora. Proverò a tornare con una soluzione adeguata.

Nginx deve avere un accesso + x a tutte le directory che portano alla directory principale del sito.

Assicurati di avere + x su tutte le directory nel percorso che porta alla radice del sito. Ad esempio, se la radice del sito è / home / nomeutente / siteroot:

chmod +x /home/
chmod +x /home/username
chmod +x /home/username/siteroot

Su CentOS 7.0 ho riscontrato questo Access Deinedproblema causato da SELinux e questi passaggi hanno risolto il problema:

yum install -y policycoreutils-devel
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp

Aggiornamento: solo una nota a margine di ciò che ho imparato durante l'utilizzo dei server Linux virtuali di digitalocean, o come li chiamano Droplet . L'uso di SELinux richiede una discreta quantità di RAM. È molto probabile che non sarai in grado di eseguire e gestire SELinux su una droplet con meno di 2 GB di RAM.

Potresti avere Linux con protezione avanzata in esecuzione, quindi aggiungi una regola per questo. Avevo 13 errori di autorizzazione, anche se i permessi erano impostati e l'utente esisteva.

chcon -Rt httpd_sys_content_t /username/test/static

Sintomo:

Impossibile caricare le immagini nella libreria multimediale di WordPress.

Causa:

(CentOS) yum update

Errore:

2014/10/22 18:08:50 [crit] 23286#0: *5332 open() "/var/lib/nginx/tmp/client_body/0000000003" failed (13: Permission denied), client: 1.2.3.4, server: _, request: "POST /wp-admin/media-new.php HTTP/1.1", host: "example.com", referrer: "http://example/wp-admin/media-new.php"

Soluzione:

chown -R www-data:www-data /var/lib/nginx

Per impostazione predefinita, i dati statici, quando installi nginx, saranno in / var / www / html. Quindi puoi semplicemente copiare la tua cartella statica in / var / html / e impostare il file

root /var/www/<your static folder>

in ngix.conf (o / etc / nginx / sites-available / default)

Questo ha funzionato per me su Ubuntu, ma immagino che non dovrebbe essere molto diverso per altre distribuzioni.

Spero che sia d'aiuto.

Cambia la tua nginx.conf userproprietà in www-staticfiles owener.

#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user your_user_name;

# same other config

Ho affrontato questo problema, l'ho risolto per dare le autorizzazioni all'utente nginx e al gruppo qualcosa del genere:

chown -R nginx:nginx /username/test/static

Nel mio caso, la cartella che serviva i file era un collegamento simbolico a un'altra cartella, realizzata con

ln -sf /origin /var/www/destination

Anche se i permessi (utente e gruppo) erano corretti sulla cartella di destinazione (il collegamento simbolico), ho comunque avuto l'errore perché Nginx doveva avere anche i permessi per l'intera gerarchia della cartella di origine.

Finalmente ho trovato la mia strada. In breve, diciamo che il tuo nome utente è joee hai un sito web sotto il tuo filesystem personale /home/joe/path/to/website.

Devi letteralmente dire al sistema che nginxè il tuo amico.
Posto nginxnel joegruppo:

sudo gpasswd -a nginx joe

Dopodiché, se ancora non funziona, controlla il diritto di accesso alla /home/joedirectory. Questo è probabilmente il motivo per cui nginx non può raggiungere il file perché anche se è tuo amico ora devi aprirgli la porta di casa tua:

sudo chmod g+x /home/joe

Questo è tutto. Questo è letteralmente tutto ciò che devi fare per dare a nginx l'accesso ai tuoi file locali :)

Non penso che ci siano problemi di sicurezza con questo metodo perché nginxè l'alta autorità e solo un amministratore può cambiare il gruppo. nginxora può leggere cosa c'è nelle joedirectory. È solo una violazione della sicurezza se il titolare nginxdell'account è diverso dall'utente da cui si apre l'accesso alla directory, ma nel mio caso sono il titolare di entrambe le parti, cioè in un contesto locale.

Ho avuto lo stesso problema, sto usando Plesk Onyx 17 con Centos7. Ho potuto vedere questo errore in proxy_error_log sotto i log del dominio interessato. Tutte le directory / file in / var / www / vhosts / sono di proprietà dei rispettivi utenti (proprietari di dominio) e puoi vedere che sono tutti nel gruppo psacln. Quindi la soluzione era aggiungere nginx anche a questo gruppo, in modo che possa vedere di cosa ha bisogno:

usermod -aG psacln nginx

E infatti, riavvia nginx e ricarica la pagina con Ctrl + F5.

Ho trovato una soluzione: ho spostato la cartella nella cartella di configurazione di nginx, nel mio caso "/ etc / nginx / my-web-app". E poi ha cambiato le autorizzazioni per l'utente root "sudo chown -R root: root" my-web-app ".

Puoi anche aggiungere quale utente eseguirà nginx. Nel file nginx.conf, apporta le seguenti modifiche:

user root;

Puoi aggiungere la riga sopra come prima riga nel tuo nginx conf. Puoi scrivere il nome di qualsiasi utente che ha il permesso di scrivere in quella directory.

Questo di solito è il problema dei privilegi ... Per me, è perché uso / root / ** come root nginx, ha bisogno di privilegi più alti. Un modo semplice è spostare il progetto in una directory creata da te.