Nginx-Fehler Verbindung zu php5-fpm.sock hergestellt fehlgeschlagen (13: Berechtigung verweigert)


290

Ich aktualisiere Nginx auf 1.4.7 und PHP auf 5.5.12 . Danach habe ich den 502-Fehler erhalten . Bevor ich aktualisiere, funktioniert alles einwandfrei.

nginx-error.log

2014/05/03 13:27:41 [crit] 4202#0: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: xx.xxx.xx.xx, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "xx.xx.xx.xx"

nginx.conf

user  www www;
worker_processes  1;

        location / {
            root   /usr/home/user/public_html;
            index  index.php index.html index.htm;
        }
        location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param  SCRIPT_FILENAME    /usr/home/user/public_html$fastcgi_script_name;
            include fastcgi_params;
        }

3
Dieser Fehlerbericht erklärt, warum dies geschieht: bugs.php.net/bug.php?id=67060
Matt Cooper

1
Jeder, der von einem Ubuntu 14 auf 16 Upgrade hierher kommt, muss die Socke auf Unix ändern: /var/run/php/php7.0-fpm.sock
Karussell

Antworten:


626

Ich hatte einen ähnlichen Fehler nach dem PHP-Update. PHP hat einen Sicherheitsfehler behoben, bei dem odie rwBerechtigung für die Socket-Datei bestand.

  1. Öffnen Sie /etc/php5/fpm/pool.d/www.confoder /etc/php/7.0/fpm/pool.d/www.conf, abhängig von Ihrer Version.
  2. Kommentieren Sie alle Berechtigungszeilen aus, z.

    listen.owner = www-data
    listen.group = www-data
    listen.mode = 0660
  3. Starten Sie fpm neu - sudo service php5-fpm restartodersudo service php7.0-fpm restart

Hinweis : Wenn Ihr Webserver als anderer Benutzer als www-data ausgeführt wird, müssen Sie die www.confDatei entsprechend aktualisieren


11
Angesichts dessen, dass der Socket für absolut jeden beschreibbar ist, kann ich nicht anders, als zu denken, dass dies eine schreckliche Lösung ist.
Shadur

11
Dieser Ansatz stellt die unsichere Standardkonfiguration wieder her, die in bugs.php.net/bug.php?id=67060 behoben wurde. Betrachten Sie stattdessen den von artooro vorgeschlagenen listen.owner-Fix.
Chris Burgess

2
Sehr verwirrend. Warum bearbeiten Sie Ihre Antwort nicht so, dass sie korrekt ist (Gehe zu / etc ...) und kommentieren Sie anschließend, wie es einen weniger sicheren Weg gibt, der nur bis zum Neustart funktioniert (Gehe zu / var / ..).
SamGoody

1
@Tecnocat Warum ist es weniger sicher? Ich denke sie sind gleich. www-data und 660. Also verstehe ich nicht, was los ist?
Xander

13
sudo usermod -aG www-data nginxermöglicht nginx den Zugriff auf die Datei
AnthumChris

107

Alle derzeit hier erwähnten Korrekturen aktivieren die Sicherheitslücke im Grunde wieder.

Am Ende habe ich meiner PHP-FPM-Konfigurationsdatei die folgenden Zeilen hinzugefügt.

listen.owner = www-data
listen.group = www-data

Stellen Sie sicher, dass www-data tatsächlich der Benutzer ist, unter dem der Nginx-Worker ausgeführt wird. Für Debian sind es standardmäßig www-Daten.

Auf diese Weise wird das Sicherheitsproblem, das durch diese Änderung behoben werden sollte, nicht aktiviert .


16
Um den ps aux|grep nginx
Nginx-

2
Auf Ubuntu unter /etc/php5/fpm/php.ini
Reality Extractor

1
@ RealityExtractor Das glaube ich nicht. Diese Datei enthält nur allgemeine PHP-Einstellungen, die nichts mit dem FPM-Prozessmanager zu tun haben.
Martijn Heemels

4
Für mich musste ich auch manuell löschen /var/run/php5-fpm.sock, da es bereits von erstellt wurde www-data. Nur ein Heads-up ...
Giel Berkers

1
Dies ist aus Sicherheitsgründen die richtige Lösung.
Jschorr

45

Die Lösung von @ Xander funktioniert, bleibt aber nach einem Neustart nicht bestehen.

Ich fand , dass ich ändern musste , listen.modeum 0660in /etc/php5/fpm/pool.d/www.conf.

Beispiel von www.conf:

; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web server. Many
; BSD-derived systems allow connections regardless of permissions. 
; Default Values: user and group are set as the running user
;                 mode is set to 0660
;listen.owner = www-data
;listen.group = www-data
;listen.mode = 0660

Bearbeiten: Per @Chris Burgess habe ich dies auf die sicherere Methode geändert.

Ich habe den Kommentar für listen.mode, .group und .owner entfernt:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

/ var / run Enthält nur Informationen zum laufenden System seit dem letzten Start, z. B. aktuell angemeldete Benutzer und laufende Daemons. ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure ).

Randnotiz:

Meine php5-fpm -vBerichte : PHP 5.4.28-1+deb.sury.org~precise+1. Das Problem trat auch nach einem kürzlich durchgeführten Update auf.


5
Dieser Ansatz stellt die unsichere Standardkonfiguration wieder her, die in bugs.php.net/bug.php?id=67060 behoben wurde. Betrachten Sie stattdessen den von artooro vorgeschlagenen listen.owner-Fix.
Chris Burgess

If listen.acl_groupsist gesetzt listen.ownerund listen.groupwird ignoriert. Ich habe eingestellt listen.acl_groups =, dann ist das 502 / Berechtigungsproblem verschwunden. Nachdem ich die listen.Zeilen wie oben auskommentiert hatte , blieb das 502-Problem bestehen und systemctl status php-fpmzeigte die Warnung an WARNING: [pool www] ACL set, listen.owner = 'nobody' is ignored.
Idoimaging

37

Wenn Sie alles in diesem Beitrag ausprobiert haben, aber keinen Erfolg damit haben, PHP zum Laufen zu bringen, wurde dies für meinen Fall behoben:

Stellen Sie sicher, dass diese Zeilen in /etc/php5/fpm/pool.d/www.conf nicht kommentiert sind:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Stellen Sie sicher, dass / etc / nginx / fastcgi_params folgendermaßen aussieht:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  PATH_INFO          $fastcgi_script_name;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Diese beiden Zeilen fehlten in meinen / etc / nginx / fastcgi_params. Stellen Sie sicher, dass sie vorhanden sind!

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  PATH_INFO          $fastcgi_script_name;

Starten Sie dann php5-fpm und nginx neu. Sollte den Trick machen.


2
Ich danke dir sehr! Ich verlor alle meine Hoffnungen, das rettete meinen Arsch.
Diego Castro

1
Du bist mein Held, du hast den Tag gerettet!
Jeppeb

1
Es gibt keine Worte, die beschreiben können, wie dankbar ich bin! Nach dem Aktualisieren der Pakete ging alles kaputt und dies rettete den Tag.
Nikola Prokopić

Ich möchte Ihnen mehr als eine +
g9m29

28

Tatsächlich sollte "listen.mode" lauten: "0660" und nicht "0666", da "Andere beschreibbar" oder "Andere lesbar" hier niemals eine gute Wahl ist.

Versuchen Sie also herauszufinden, welcher Benutzer / welche Gruppe Ihr Webserver ausführt. Ich benutze CentOs und es läuft als Benutzer "nginx". Also füge es deiner php-fpm.conf hinzu:

listen.owner = nginx
listen.group = nginx
listen.mode = 0660

endlich php-fpm neu starten


Für das, was es wert ist, sind auf meinem Ubuntu 12.04-System der Benutzer und die Gruppe www-data.
Brad

1
Für mich in CentOS hat es funktioniert, den Benutzer als "niemand" und die Gruppe als "nginx" festzulegen. Wahrscheinlich keine wesentliche Verbesserung, aber ich würde es vorziehen, möglichst begrenzte Berechtigungen zu erteilen.
Kzqai

23

Überprüfen Sie, welcher Benutzer nginx ausführt. Ab Ubuntu 12.04 wird nginx von einem nginx-Benutzer ausgeführt, der kein Mitglied der www-Datengruppe ist.

usermod -a -G www-data nginx

Ein Neustart von nginx- und php5-fpm-Daemons löst das Problem.


Dieses Update scheint in Bezug auf die Sicherheit das sauberste zu sein. Arbeitete unter Ubuntu 14.04, Nginx 1.7.10, PHP 5.5.9-1ubuntu4.6 (fpm-fcgi)
AnthumChris

12

Alternativ zur Erweiterung der Berechtigungen in Ihrer PHP-Konfiguration können Sie den in Ihrer Nginx-Konfiguration angegebenen Benutzer ändern.

In der ersten Zeile Ihres nginx.conf-Auszugs oben werden der Benutzer und die Gruppe als www bzw. www angegeben.

user  www www;

In der Zwischenzeit gibt Ihre PHP-Konfiguration wahrscheinlich einen Benutzer und eine Gruppe von WWW-Daten an:

listen.owner = www-data
listen.group = www-data

Sie können die Zeile in Ihrer nginx.conf in eine der folgenden ändern:

user www-data www;
user www-data www-data; # or any group, really, since you have the user matching
user www www-data; # requires that your php listen.mode gives rw access to the group

Vielen Dank!
Aline Matos

Vielen Dank! Die Änderung von nginx.conf ist erforderlich.
LCB

7

Gegebenenfalls müssen auch Ihre individuellen FPM-Pools berücksichtigt werden.

Ich konnte nicht herausfinden, warum keine dieser Antworten heute für mich funktionierte. Dies war für mich ein Set-and-Forget-Szenario gewesen, bei dem ich vergessen hatte, dass listen.user und listen.group pro Pool dupliziert wurden.

Wenn Sie wie ich Pools für verschiedene Benutzerkonten verwendet haben, in denen jedes Benutzerkonto seine FPM-Prozesse und -Sockets besitzt, funktioniert es einfach nicht, nur die Standardkonfigurationsoptionen listen.owner und listen.group auf 'nginx' zu setzen. Und natürlich ist es auch nicht akzeptabel, 'Nginx' sie alle besitzen zu lassen.

Stellen Sie für jeden Pool sicher, dass

listen.group = nginx

Andernfalls können Sie das Eigentum des Pools und dergleichen in Ruhe lassen.


Danke dir. Wenn Ngnix für verschiedene Benutzerkonten funktioniert, sollte dies wie folgt geändert werden: "listen.group = nginx"
MURATSPLAT

6

Ich habe diesen Fehler heute erneut erhalten, als ich meinen Computer (mit Updates für PHP) unter Ubuntu 14.04 aktualisiert habe . Die Distributionskonfigurationsdatei /etc/php5/fpm/pool.d/www.confist in Ordnung und erfordert derzeit keine Änderungen.

Ich habe folgende Fehler gefunden:

dmesg | grep php
[...]
[ 4996.801789] traps: php5-fpm[23231] general protection ip:6c60d1 sp:7fff3f8c68f0 error:0 in php5-fpm[400000+800000]
[ 6788.335355] traps: php5-fpm[9069] general protection ip:6c5d81 sp:7fff98dd9a00 error:0 in php5-fpm[400000+7ff000]

Das Merkwürdige war , dass ich 2 Seiten ausgeführt , dass PHP-FPM auf dieser Maschine eines verwenden fein ausgeführt wurden und die andere (a Tiny Tiny RSS - Installation) gab mir ein 502, wo beide ausgeführt wurden fein vor .

Ich habe beide Konfigurationsdateien verglichen und festgestellt, dass diese fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;für die betroffene Site fehlten.

Beide Konfigurationsdateien enthalten jetzt den folgenden Block und laufen wieder einwandfrei:

location ~ \.php$ {
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        include /etc/nginx/snippets/fastcgi-php.conf;
}

Aktualisieren

Es ist zu beachten, dass Ubuntu zwei Fastcgi-bezogene Parameterdateien sowie ein Konfigurations-Snippet liefert, das seit Vivid und auch in der PPA- Version verfügbar ist . Die Lösung wurde entsprechend aktualisiert.

Diff der fastcgi-Parameterdateien:

$ diff -up fastcgi_params fastcgi.conf
--- fastcgi_params      2015-07-22 01:42:39.000000000 +0200
+++ fastcgi.conf        2015-07-22 01:42:39.000000000 +0200
@@ -1,4 +1,5 @@

+fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
 fastcgi_param  QUERY_STRING       $query_string;
 fastcgi_param  REQUEST_METHOD     $request_method;
 fastcgi_param  CONTENT_TYPE       $content_type;

Konfigurations-Snippet in /etc/nginx/snippets/fastcgi-php.conf

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;

3
Vielen Dank. Ich habe das gleiche Problem. Es ist seltsam, dass im Paket diese Zeile nicht enthalten ist. Ich füge es einfach zu / etc / nginx / fastcgi_params hinzu und alles funktioniert jetzt wieder.
Bukashk0zzz

5

Die folgende einfache Lösung hat bei mir funktioniert und mögliche Berechtigungsprobleme mit dem Socket umgangen.

Setzen Sie in Ihrer Nginx-Konfiguration fastcgi_pass auf:

fastcgi_pass   127.0.0.1:9000;

Anstatt

fastcgi_pass   /var/run/php5-fpm.sock;

Dies muss mit dem Parameter listen = in /etc/php5/fpm/pool.d/www.conf übereinstimmen. Setzen Sie dies daher auch auf:

listen = 127.0.0.1:9000;

Starten Sie dann php5-fpm und nginx neu

service php5-fpm restart

Und

service nginx restart

Weitere Informationen finden Sie unter: https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm/


Dies kann zwar eine Lösung finden, ist jedoch keine Lösung zur Behebung eines Sockenproblems.
Chris

5

Das Problem in meinem Fall war, dass der Nginx-Webserver als Benutzer nginx und der Pool als Benutzer www-data ausgeführt wurde.

Ich habe das Problem gelöst, indem ich den Benutzer geändert habe, unter dem Nginx in der /etc/nginx/nginx.confDatei ausgeführt wird (könnte auf Ihrem System anders sein, meins ist Ubuntu 16.04.1).

Veränderung: user nginx;

zu: user www-data;

Starten Sie dann Nginx neu: service nginx restart


4

Einfach aber funktioniert ..

listen.owner = nginx
listen.group = nginx

chown nginx:nginx /var/run/php-fpm/php-fpm.sock

Soweit ich weiß, überlebt dies einen Neustart nicht, ist also eher eine vorübergehende Korrektur.
Chris

4

Ich habe das gleiche Problem unter Amazon Linux AMI 2016.09 (Centos 7) behoben, indem ich die folgenden Schritte ausgeführt habe.

Öffnen Sie Ihre www.conf- Dateien (Beispiel: sudo nano /etc/php-fpm.d/www.conf). Suchen Sie zuletzt die Zeilen, in denen listen.owner und listen.group festgelegt sind, und ändern Sie ihre Werte von "Nobody" in "nginx" ":

listen.owner = nginx
listen.group = nginx
listen.mode = 0666

Zuletzt suchen Sie die Zeilen, die den Benutzer und die Gruppe festlegen, und ändern ihre Werte von "Apache" in "Nginx":

user = nginx
group = nginx

Starten Sie php-fpm neu (sudo service php-fpm restart)


2
Verwenden Sie 660 anstelle von 666. 666 ist unsicher und wurde durch diesen Patch behoben. Bugs.php.net/…
Xander

3

Das Wichtigste dabei ist, welcher Benutzer Nginx verwendet, und Sie müssen es auch angeben

in Ihrer nginx.conf

user www-data;
worker_processes  1;

        location / {
            root   /usr/home/user/public_html;
            index  index.php index.html index.htm;
        }
        location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param  SCRIPT_FILENAME    /usr/home/user/public_html$fastcgi_script_name;
            include fastcgi_params;
        }

in Ihrer www.conf

listen.owner = www-data
listen.group = www-data
;listen.mode = 0660

In Ihrem Fall ist der Benutzer und die Gruppe "www". Ersetzen Sie sie einfach.

  • Starten Sie Nginx und PHP Fpm neu

2

Wenn Sie einen unterschiedlichen Pool pro Benutzer haben, stellen Sie sicher, dass Benutzer und Gruppe in der Konfigurationsdatei richtig eingestellt sind. Sie finden den nginx-Benutzer in der Datei /etc/nginx/nginx.conf. Die Nginx-Gruppe ist dieselbe wie der Nginx-Benutzer.

user = [pool-user]
group = [pool-group]
listen.owner = [nginx-user]
listen.group = [nginx-group]

2

Überprüfen Sie auch SELINUX (/ etc / selinux):

# getenforce

schalte es aus:

# setenforce 0

1
Sie sollten sich niemals dafür entscheiden, die Sicherheit eines Systems zu verringern, damit etwas funktioniert, sondern eine der vielen Optionen in den anderen Antworten verwenden, um Ihr Problem zu lösen. Deaktivieren Sie Selinux nicht ohne guten Grund!
SlyDave

2

In meinem Fall lief php-fpm überhaupt nicht, also musste ich nur den Dienst starten 😂

service php7.3-fpm start
#on ubuntu 18.04

2

Siehe nur /etc/php5/php-fpm.conf pid = /var/run/php5-fpm.pidIS PID-Datei

Im Ordner /etc/php5/fpm/pool.d/www.conf

listen = /var/run/php5-fpm.sock IS SOCKET-Datei

Wenn Sie gleich pid hören ( pid = /var/run/php5-fpm.sock and listen = /var/run/php5-fpm.sock) -> falsche Einstellungen und beenden Sie die Einstellung/etc/php5/fpm/pool.d/www.conf

user = nginx
group = nginx
listen.owner = nginx
listen.group = nginx
listen.mode = 0660

1

Unter CentOS (und wahrscheinlich Red Hat und Fedora) befindet sich die Datei, in die die Berechtigungen geändert werden sollen, unter:

/etc/php-fpm.d/www.conf


1

Nach dem Upgrade von Ubuntu 14.04 auf Ubuntu 16.04 habe ich einen weiteren Grund für diesen Fehler gefunden, den ich vorher noch nicht gesehen habe.

Während des Upgrades hatte ich irgendwie meine ausführbare Datei php5-fpm verloren. Alle Konfigurationsdateien waren intakt und es dauerte eine Weile, bis mir klar wurde, dass service php5-fpm startein Prozess nicht wirklich gestartet wurde, da keine Fehler angezeigt wurden.

Mein Moment des Erwachens war, als ich bemerkte, dass keine Socket-Datei darin war /var/run/php5-fpm.sock, wie es sein sollte, noch tatnetstat -an Prozesse zeigte, die den Port abhörten, den ich als Alternative versuchte, um dieses Problem zu lösen. Da die Datei / usr / sbin / php5-fpm ebenfalls nicht vorhanden war, war ich endlich auf dem richtigen Weg.

Um dieses Problem zu lösen, habe ich PHP von Version 5.5 auf 7.0 aktualisiert. apt-get install php-fpmtat den Trick als Nebeneffekt. Danach und nach der Installation anderer notwendiger Pakete war alles wieder normal.


Diese Upgrade-Lösung kann eigene Probleme haben . Da sich PHP ziemlich weiterentwickelt hat, ist es möglich, dass die Software auf unvorstellbare Weise kaputt geht. Obwohl ich diesen Weg eingeschlagen habe, möchten Sie vielleicht die Version, die Sie mögen, noch eine Weile behalten.

Glücklicherweise scheint es dafür einen guten Weg zu geben , wie auf der Windows-Website "Anpassen" beschrieben:

add-apt-repository ppa:ondrej/php
apt-get purge php5-common
apt-get update
apt-get install php5.6

So ordentlich die Lösung auch sein mag, das habe ich nicht versucht. Ich gehe davon aus, dass mir die nächsten Tage sagen werden, ob ich es hätte tun sollen.


1

Ich hatte den ähnlichen Fehler.

Alle Empfehlungen haben nicht geholfen.

Der einzige Ersatz für WWW-Daten durch Nginx hat geholfen:

$ sudo chmod nginx:nginx /var/run/php/php7.2-fpm.sock

/var/www/php/fpm/pool.d/www.conf

user = nginx
group = nginx
...
listen.owner = nginx
listen.group = nginx
listen.mode = 0660

Hey @Alexander, Sie müssen den Befehl chown verwenden, um die Besitzer in nginx zu ändern. Das hat mir sehr geholfen.
Pratik Ghela

0

Ich habe das Betriebssystem auf meinem Server einige Male geändert, um das komfortabelste System zu erhalten.

Früher hat es die meiste Zeit sehr gut funktioniert, aber zuletzt habe ich diesen 502 Gateway-Fehler erhalten.

Ich benutze einen PHP-Fpm-Socket für jedes Konto, anstatt für alle das gleiche zu behalten. Wenn also eine abstürzt, laufen zumindest die anderen Anwendungen weiter.

Früher hatte ich Benutzer- und Gruppen-WWW-Daten. Dies änderte sich jedoch auf meinem Debian 8 mit dem neuesten Nginx 1.8 und php5-fpm.

Der Standardbenutzer ist nginx, ebenso wie die Gruppe. Um dies sicherzustellen, überprüfen Sie am besten die Dateien / etc / group und / etc / passwd. Diese können nicht lügen.

Dort habe ich festgestellt, dass ich jetzt Nginx in beiden habe und keine WWW-Daten mehr.

Vielleicht kann dies einigen Leuten helfen, die immer noch versuchen herauszufinden, warum die Fehlermeldung immer wieder auftaucht.

Es hat bei mir funktioniert.


0

An diejenigen, die alles in diesem Thread ausprobiert haben und trotzdem feststeckten: Dies hat mein Problem gelöst. Ich habe /usr/local/nginx/conf/nginx.conf aktualisiert

  1. Kommentieren Sie die Zeile aus user

  2. mach es www-dataso, dass es wird:user www-data;

  3. Speichern Sie es (Root-Zugriff erforderlich)

  4. Starten Sie nginx neu


0

Wenn Sie Erklärungen haben

pid = /run/php-fpm.pid

und

listen = /run/php-fpm.pid

In verschiedenen Konfigurationsdateien wird root Eigentümer dieser Datei.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.