PHP FPM concede l'autorizzazione negata?


9

Ho letto diverse voci sul perché PHP-FPM potrebbe darmi il permesso negato ma non riesco a risolverlo.

I log degli errori hanno il seguente aspetto:

    2013/04/20 23:33:28 [crit] 15479#0: *6 open() "/var/lib/nginx/tmp/fastcgi
/2/00/0000000002" failed (13: Permission denied) while reading upstream, client: 
99.999.999.999, server: example.net, request: "GET /wp-admin/ HTTP/1.1", 
upstream: "fastcgi://unix:/tmp/php-fpm.sock:", host: "example.net", referrer:    
"http://example.net/"

Sono un po 'perso ma:

  1. Ho impostato / var / lib / nginx / tmp su ec2-user (ho anche +777 tutto da controllare)
  2. Ho impostato /tmp/php-fpm.sock su ec2-user
  3. il file conf nginx è impostato su ec2-user
  4. php-conf è impostato su user e group ec2-user
  5. ps aux fornisce all'utente ec2 su tutti i processi php-fpm e nginx

La mia configurazione di Nginx include molti file, la configurazione di base è:

user              ec2-user ec2-user;
worker_processes  5;  
error_log /opt/nginx/error.log;    
pid        /var/run/nginx.pid;    
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;    
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log /opt/nginx/access.log main;    
    sendfile        on;
    keepalive_timeout  65;
    client_max_body_size 13m;
    index index.php index.html index.htm;
    upstream php {
       server unix:/tmp/php-fpm.sock;
    }
    include /etc/nginx/conf.d/*.conf;
    include /mnt/web/nginx/conf.d/*.conf;
}

il mio /etc/nginx/conf.d/ è vuoto il mio /mnt/web/nginx/conf.d contiene MOLTE configurazioni del sito Web che includono tutte "wordpress.conf":

location / {
    try_files $uri $uri/ /index.php?$args;
}
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 24h;
    log_not_found off;
}
location ~ \.php$ {
    try_files $uri =404;    
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass php;
}

Il mio /opt/php/etc/php-fpm.conf:

include=/opt/php/etc/fpm.d/*.conf
pid = run/php-fpm.pid
error_log = log/php-fpm.log
log_level = notice
[www]
listen = /tmp/php-fpm.sock
user = ec2-user
group = ec2-user
pm = dynamic
pm.max_children = 250
pm.start_servers = 20
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 500
pm.status_path = /fpm-status
ping.path = /fpm-ping
slowlog = log/$pool.log.slow
catch_workers_output = yes

AGGIORNAMENTO: trovato il problema, inserirlo nella risposta


1
selinux è abilitato? eseguire getenforce o cat / selinux / enforce se non è 0 abilitato
— silviud

1
Qual è il resto della tua configurazione nginx?
— Michael Hampton,

1
il tuo socket dal file di registro è /tmp/php-fpm.sock ma hai cambiato / var / lib / nginx / tmp - hai fatto chroot in nginx?
— silviud,

1
invia l'output dal comando mount
— silviud

1
guarda anche che tutte le directory di casa tua ... vedi serverfault.com/questions/170192/…
— silviud

Risposte:


16

Avevo impostato / var / lib / nginx / tmp su ec2-user / ec2-user (ho anche +777 tutto da controllare)

Ma ... ho anche dovuto impostare / var / lib / nginx su ec2-user / ec2-user

... dopo anche chown / chgrp la cartella nginx principale: niente più errori.

Mi ci sono volute alcune ore ...


7
chown -Rf www-data:www-data /var/lib/nginxha funzionato per me. non avevo bisogno di cambiare niente.
— Chris,

il controllo dei file di registro aiuta sempre, ricordati di controllarli prima di ogni altra cosa :)
— poesia del dolore

9

Questo generalmente accade. Quando l' userimpostazione in nginx.conf viene modificata

user nginx;

a qualcos'altro. In questo caso,

user ec2-user ec2-user;

Il comando chmod non è necessario per il commento di Chris e potrebbe aprire una falla di sicurezza.

Soluzione:

Controlla la proprietà dell'utente e del gruppo corrente su / var / lib / nginx.

$ ls -ld /var/lib/nginx
drwx------ 3 nginx nginx 4096 Aug  5 00:05 /var/lib/nginx

Questo ti dice che un utente e un gruppo possibilmente inesistenti nominati nginxpossiedono questa cartella. Questo impedisce il caricamento di file.

Modificare la proprietà della cartella con l'utente definito in nginx.conf in questo caso ec2-user(sudo potrebbe non essere necessario).

$ sudo chown -Rf ec2-user:ec2-user /var/lib/nginx

Verifica che sia effettivamente cambiato.

$ ls -ld /var/lib/nginx
drwx------ 3 ec2-user ec2-user 4096 Aug  5 00:05 /var/lib/nginx

L'errore di autorizzazione negata dovrebbe ora scomparire. Controllare error.log (basato sulla posizione nginx.conf error_log).

$ sudo nano /opt/nginx/error.log

Se il problema persiste, potrebbe essere necessario ricaricare nginx e php-fpm.

$ sudo service nginx reload
$ sudo service php-fpm reload

Questo ha funzionato sul mio server Centos 7 di Google Cloud.
— Damodar Bashyal,

3

Nessuna delle altre soluzioni ha funzionato per me, ma ho scoperto che funzionava:

$ apt-get install php-pear php5-dev
$ pecl install timezonedb
$ echo 'extension=timezonedb.so'> /etc/php5/mods-available/timezonedb.ini
$ ln -sf /etc/php5/mods-available/timezonedb.ini /etc/php5/conf.d/30-timezonedb.ini
$ service php5-fpm restart

fonte


Ok, abbiamo provato diverse soluzioni e questa è quella che ha funzionato. Non sappiamo perché ha funzionato o quale fosse il problema, ma ha funzionato.
— Neil Masters,

1

Ho il problema simile con il caricamento di file. Errore nginx 500 2015/07/05 03:50:36 [crit] 3656#0: *7 open() "/var/lib/nginx/tmp/client_body/0000000007" failed (13: Permission denied), client: 10.0.2.2, server: www.test.com, request: "POST /api/v1/users HTTP/1.1", host: "test"

Il problema era legato solo al permesso, ho appena impostato chmod -R 755 /var/lib/nginxe le cose hanno funzionato!


0

Ho appena risolto il mio problema con le autorizzazioni. Il modo più semplice e più semplice era di non eseguire php-fpm o nginx come sudo (super user). Quello che dovresti fare è:

  1. chown tutte le posizioni di output del registro per nginx in yourUserName: esempio yourUserName :chown yourUserName:yourUserName /var/log/nginx/error.log
  2. Prossimo dir server di aggiornamento, nonché ad esempio :chown yourUserName:yourUserName -R /var/www

Non usando root non ho dovuto cambiare utente o gruppo php-fpm o nessun utente o gruppo in ascolto. Assicurati di commentare anche nginx.conf 'user' in quanto sarà il nome dell'utente corrente.


Si prega di non pubblicare la stessa risposta più volte. Inoltre, questo problema è stato a lungo risolto.
— Sven

0

Invece di modificare le autorizzazioni su / var / lib / nginx / qualunque cosa, non avrebbe più senso dire a nginx di usare un percorso diverso come / tmp / nginx? Ciò ha risolto il problema per me:

# create the directory
mkdir /tmp/nginx
chown -R nginx.nginx /tmp/nginx (assumes nginx user is named nginx)
chmod -R 700 /tmp/nginx

Le autorizzazioni / tmp / nginx dovrebbero essere preferibilmente 700 (il che non dovrebbe essere un problema fintanto che il proprietario è lo stesso utente specificato nella direttiva 'user' /etc/nginx/nginx.conf) o 770 se per qualche motivo è necessario hanno un proprietario di file e nginx diversi per eseguire gli I / O tramite autorizzazioni di gruppo. Non l'ho mai visto, ma chi lo sa.

Su centos7, modifica /etc/nginx/nginx.conf per dire a nginx di usare quella nuova directory per i corpi client

...

http {
  ...
  client_body_temp_path /tmp/nginx 1 2;
  ...
}

e riavvia nginx (di nuovo centos7)

systemctl restart nginx

Mai chmod 777 nulla. Soprattutto non nella cache! Ora qualsiasi utente locale può riscrivere la cache e inviare dati potenzialmente dannosi ai tuoi utenti. Per i caricamenti, invece, qualcuno potrebbe sostituire il proprio caricamento.
— Michael Hampton,

Gesù amico, rilassati, questa build fa parte di un cluster demo. Ma buona cattura per le persone che potrebbero non conoscere meglio, modificherò la risposta.
— siliconrockstar,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.