Błąd nginx połączenie z php5-fpm.sock nie powiodło się (13: Odmowa uprawnień)


290

Aktualizuję nginx do 1.4.7 i php do 5.5.12 , po czym dostałem błąd 502 . Przed aktualizacją wszystko działa dobrze.

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
Ten raport o błędach wyjaśnia, dlaczego tak się dzieje: bugs.php.net/bug.php?id=67060
Matt Cooper

1
Wszyscy przychodzący tutaj z aktualizacji Ubuntu 14 do 16, musisz zmienić skarpetę na unix: /var/run/php/php7.0-fpm.sock
Karussell

Odpowiedzi:


626

Miałem podobny błąd po aktualizacji php. PHP naprawiło błąd bezpieczeństwa, który omiał rwuprawnienia do pliku gniazda.

  1. Otwórz /etc/php5/fpm/pool.d/www.conflub /etc/php/7.0/fpm/pool.d/www.conf, w zależności od wersji.
  2. Odkomentuj wszystkie linie uprawnień, takie jak:

    listen.owner = www-data
    listen.group = www-data
    listen.mode = 0660
    
  3. Uruchom ponownie fpm - sudo service php5-fpm restartlubsudo service php7.0-fpm restart

Uwaga : jeśli twój serwer działa jako użytkownik inny niż www-data, musisz odpowiednio zaktualizować www.confplik


11
Biorąc pod uwagę, że dzięki temu gniazdko można zapisać absolutnie dla wszystkich, nie mogę przestać myśleć, że to okropne rozwiązanie.
Shadur

11
To podejście przywraca niepewną domyślną konfigurację rozwiązaną w bugs.php.net/bug.php?id=67060 - zamiast tego rozważ poprawkę listen.owner sugerowaną przez artooro.
Chris Burgess

2
Bardzo mylące. Dlaczego nie poprawisz swojej odpowiedzi, aby była poprawna, (Idź do / etc ...), a następnie skomentuj, w jaki sposób istnieje mniej bezpieczny sposób, który działa tylko do ponownego uruchomienia (Idź do / var / ..).
SamGoody

1
@Tecnocat Dlaczego to mniej bezpieczne? Myślę, że są takie same. www-data i 660. Więc nie rozumiem, co jest nie tak?
Xander,

13
sudo usermod -aG www-data nginxumożliwia nginx dostęp do pliku
AnthumChris

107

Wszystkie wspomniane obecnie poprawki zasadniczo powodują ponowne otwarcie dziury w zabezpieczeniach.

Skończyło się na tym, że dodałem następujące wiersze do mojego pliku konfiguracyjnego PHP-FPM.

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

Upewnij się, że dane www to tak naprawdę użytkownik, na którym działa pracownik nginx. W przypadku Debiana domyślnie są to dane www.

Wykonanie tego w ten sposób nie włącza problemu bezpieczeństwa, który ta zmiana miała naprawić .


16
Aby sprawdzić nazwę użytkownika nginxps aux|grep nginx
SamGoody

2
Na Ubuntu na /etc/php5/fpm/php.ini
Reality Extractor

1
@RealityExtractor Nie sądzę. Ten plik zawiera tylko ogólne ustawienia PHP, nic nie związane z menedżerem procesów FPM.
Martijn Heemels,

4
Dla mnie musiałem również ręcznie usunąć /var/run/php5-fpm.sock, ponieważ został już utworzony przez www-data. Tylko heads-up ...
Giel Berkers

1
Jest to poprawna poprawka pod względem bezpieczeństwa.
jschorr

45

Rozwiązanie @ Xander działa, ale nie utrzymuje się po ponownym uruchomieniu.

Okazało się, że musiałem zmienić listen.modesię 0660w /etc/php5/fpm/pool.d/www.conf.

Próbka z 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

Edycja: Na @Chris Burgess zmieniłem to na bezpieczniejszą metodę.

Usunąłem komentarz dla Listen.mode, .group i .owner:

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

/ var / run Przechowuje tylko informacje o systemie uruchomionym od ostatniego uruchomienia, np. aktualnie zalogowani użytkownicy i uruchomione demony. ( http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure ).

Dygresja:

Moje php5-fpm -vraporty: PHP 5.4.28-1+deb.sury.org~precise+1. Problem pojawił się również po ostatniej aktualizacji.


5
To podejście przywraca niepewną domyślną konfigurację rozwiązaną w bugs.php.net/bug.php?id=67060 - zamiast tego rozważ poprawkę listen.owner sugerowaną przez artooro.
Chris Burgess

Jeśli listen.acl_groupsjest ustawione listen.owneri listen.groupsą ignorowane. Ustawiłem listen.acl_groups =, a następnie problem 502 / uprawnień zniknął. Znalazłem go po odkomentowaniu listen.linii jak wyżej, problem 502 nadal występował i systemctl status php-fpmpokazał ostrzeżenie WARNING: [pool www] ACL set, listen.owner = 'nobody' is ignored.
idoimaging

37

Jeśli wypróbowałeś już wszystko w tym poście, ale nie udało ci się uzyskać PHP do pracy, to naprawiło to w moim przypadku:

Upewnij się, że te wiersze nie są komentowane w /etc/php5/fpm/pool.d/www.conf:

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

Upewnij się, że / etc / nginx / fastcgi_params wygląda następująco:

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;

Tych dwóch linii brakowało w moim / etc / nginx / fastcgi_params, upewnij się, że tam są!

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

Następnie zrestartuj php5-fpm i nginx. Powinien załatwić sprawę.


2
Dziękuję bardzo! Straciłem wszystkie nadzieje, to uratowało mi tyłek.
Diego Castro

1
Jesteś moim bohaterem, uratowałeś dzień!
jeppeb

1
Nie ma słów, które mogłyby opisać, jak wdzięczny jestem! Po aktualizacji pakietów wszystko poszło kaput i to uratowało dzień.
Nikola Prokopić

Chcę dać ci więcej niż jeden +
g9m29

28

W rzeczywistości „Listen.mode” powinno brzmieć: „0660”, a nie „0666”, ponieważ Inne zapisywalne lub inne czytelne nigdy nie są tutaj dobrym wyborem.

Spróbuj więc dowiedzieć się, który użytkownik / grupa działa na twoim serwerze. Używam CentO i działa jako użytkownik „nginx”. Dodaj więc do swojego php-fpm.conf:

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

w końcu zrestartuj php-fpm


Za to, co jest warte, w moim systemie Ubuntu 12.04, użytkownik i grupa są www-data.
Brad

1
Dla mnie w CentOS działało, aby ustawić użytkownika jako „nikt”, a grupę jako „nginx”. Prawdopodobnie nie jest to znacząca poprawa, ale wolałbym dać tak ograniczone uprawnienia, jak to możliwe.
Kzqai,

23

Sprawdź, który użytkownik uruchamia nginx. Począwszy od Ubuntu 12.04 nginx jest uruchamiany przez użytkownika nginx, który nie jest członkiem grupy danych www.

usermod -a -G www-data nginx

i ponowne uruchomienie demonów nginx i php5-fpm rozwiązuje problem.


Ta poprawka wydaje się najczystsza pod względem bezpieczeństwa. Pracował na Ubuntu 14.04, Nginx 1.7.10, PHP 5.5.9-1ubuntu4.6 (fpm-fcgi)
AnthumChris

12

Alternatywnie do rozszerzania uprawnień w konfiguracji php, możesz zmienić użytkownika określonego w konfiguracji nginx.

W pierwszym wierszu fragmentu nginx.conf powyżej użytkownik i grupa są określone odpowiednio jako www i www.

user  www www;

Tymczasem twoja konfiguracja php prawdopodobnie określa użytkownika i grupę danych www:

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

Możesz zmienić wiersz w pliku nginx.conf na dowolny z poniższych, a następnie:

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

Dziękuję Ci bardzo!
Aline Matos

Dziękuję Ci bardzo! Konieczna jest zmiana pliku nginx.conf.
LCB,

7

Należy również wziąć pod uwagę ewentualne indywidualne pule FPM.

Nie mogłem zrozumieć, dlaczego żadna z tych odpowiedzi nie działała dzisiaj dla mnie. Był to dla mnie scenariusz „ustaw i zapomnij”, w którym zapomniałem, że listen.user i listen.group zostały zduplikowane dla poszczególnych pul.

Jeśli używałeś pul dla różnych kont użytkowników, tak jak ja, gdzie każde konto użytkownika ma swoje procesy i gniazda FPM, ustawienie tylko domyślnych opcji konfiguracji nasłuchiwania i nasłuchiwania grupy na „nginx” po prostu nie zadziała. I oczywiście, pozwolenie, by „nginx” był ich właścicielem, jest również nie do przyjęcia.

Upewnij się, że dla każdej puli

listen.group = nginx

W przeciwnym razie możesz zostawić własność puli i takie w spokoju.


Dziękuję Ci. Jeśli Ngnix działa na różnych kontach użytkowników, należy zmienić w ten sposób: „listen.group = nginx”
MURATSPLAT,

6

Właśnie dostałem ten błąd dzisiaj, kiedy zaktualizowałem swój komputer (z aktualizacjami dla PHP) z Ubuntu 14.04 . Plik konfiguracyjny dystrybucji /etc/php5/fpm/pool.d/www.confjest w porządku i obecnie nie wymaga żadnych zmian.

Znalazłem następujące błędy:

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]

Dziwną rzeczą było to, że mam uruchomione 2 strony wykorzystujące PHP-FPM na tej maszynie, jedna działała dobrze, a druga (instalacja Tiny Tiny RSS) dała mi 502, przy czym obie działały wcześniej dobrze .

Porównałem oba pliki konfiguracyjne i okazało się, że fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;brakowało tej witryny.

Oba pliki konfiguracyjne zawierają teraz następujący blok i działają poprawnie:

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

Aktualizacja

Należy zauważyć, że Ubuntu dostarcza dwa pliki parametrów związane z fastcgi, a także fragment konfiguracji, który jest dostępny od Vivid, a także w wersji PPA . Rozwiązanie zostało odpowiednio zaktualizowane.

Zróżnicowane pliki parametrów fastcgi:

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

Fragment konfiguracji w /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
Wielkie dzięki. Mam ten sam problem. Dziwne, że w pakiecie nie ma tej linii. Po prostu dodałem go do / etc / nginx / fastcgi_params i wszystko działa teraz ponownie.
Bukashk0zzz

5

Poniższa prosta poprawka zadziałała dla mnie, omijając możliwe problemy z uprawnieniami w gnieździe.

W konfiguracji nginx ustaw fastcgi_pass na:

fastcgi_pass   127.0.0.1:9000;

Zamiast

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

Musi to zgadzać się z parametrem listen = w /etc/php5/fpm/pool.d/www.conf, więc ustaw także:

listen = 127.0.0.1:9000;

Następnie uruchom ponownie php5-fpm i nginx

service php5-fpm restart

I

service nginx restart

Aby uzyskać więcej informacji, zobacz: https://wildlyinaccurate.com/solving-502-bad-gateway-with-nginx-php-fpm/


Choć może się to zdarzyć, nie jest to rozwiązanie problemu ze skarpetami.
Chris

5

Problem w moim przypadku polegał na tym, że serwer WWW Nginx działał jako użytkownik nginx, a pula działała jako dane www użytkownika.

Rozwiązałem problem, zmieniając użytkownika, na którym działa Nginx w /etc/nginx/nginx.conf pliku (może być inny w twoim systemie, mój to Ubuntu 16.04.1)

Zmiana: user nginx;

do: user www-data;

następnie uruchom ponownie Nginx: service nginx restart


4

Proste, ale działa ..

listen.owner = nginx
listen.group = nginx

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

Jak rozumiem, nie przetrwa to ponownego uruchomienia, więc jest to raczej tymczasowa poprawka.
Chris

4

Naprawiłem ten sam problem na Amazon Linux AMI 2016.09 (Centos 7), wykonując następujące kroki.

Otwórz pliki www.conf (przykład: sudo nano /etc/php-fpm.d/www.conf) Na koniec znajdź linie, które ustawiają listen.owner i listen.group i zmień ich wartości z „nobody” na „nginx” „:

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

Na koniec znajdź linie, które ustawiają użytkownika i grupę, i zmień ich wartości z „apache” na „nginx”:

user = nginx
group = nginx

Uruchom ponownie php-fpm (usługa sudo php-fpm restart)


2
Użyj 660 zamiast 666. 666 jest niepewny i został naprawiony przez tę łatkę bugs.php.net/…
Xander

3

Najważniejszą rzeczą tutaj jest to, który użytkownik używa nginx, a następnie musisz go również podać

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

w twoim www.conf

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

w twoim przypadku użytkownik i grupa to „www”, więc po prostu go zastąp.

  • zrestartuj nginx i php fpm

2

Jeśli masz inną pulę dla użytkownika, upewnij się, że użytkownik i grupa są poprawnie ustawione w pliku konfiguracyjnym. Możesz znaleźć użytkownika nginx w pliku /etc/nginx/nginx.conf. Grupa nginx jest taka sama jak użytkownik nginx.

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

2

Sprawdź także SELINUX (/ etc / selinux):

# getenforce

Wyłącz to:

# setenforce 0

1
Nigdy nie powinieneś decydować się na zmniejszenie bezpieczeństwa systemu, aby coś działało, zamiast tego użyj jednej z wielu opcji w pozostałych odpowiedziach, aby rozwiązać problem. Nie wyłączaj selinux bez bardzo dobrego powodu!
SlyDave

2

Zobacz /etc/php5/php-fpm.conf pid = /var/run/php5-fpm.pidplik IS PID

W pliku /etc/php5/fpm/pool.d/www.conf

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

jeśli pid równa nasłuchiwanie ( pid = /var/run/php5-fpm.sock and listen = /var/run/php5-fpm.sock) -> złe ustawienia i zakończenie ustawiania/etc/php5/fpm/pool.d/www.conf

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

1

Po aktualizacji z Ubuntu 14.04 lts do Ubuntu 16.04 lts znalazłem jeszcze jeden powód tego błędu, którego nie widziałem wcześniej.

Podczas procesu aktualizacji jakoś straciłem mój plik wykonywalny php5-fpm. Wszystkie pliki konfiguracyjne były nienaruszone i zajęło mi to trochę czasuservice php5-fpm start tak naprawdę nie uruchomiłem procesu, ponieważ nie pokazałem żadnych błędów.

Mój moment przebudzenia nastąpił, gdy zauważyłem, że nie ma pliku gniazda /var/run/php5-fpm.sock, tak jak powinien, ani nie netstat -anpokazałem procesów nasłuchujących na porcie, które próbowałem alternatywnie, próbując rozwiązać ten problem. Ponieważ plik / usr / sbin / php5-fpm również nie istniał, w końcu byłem na dobrej drodze.

Aby rozwiązać ten problem zaktualizowałem php z wersji 5.5 do 7.0. apt-get install php-fpmzrobił lewę jako efekt uboczny. Po zainstalowaniu innych niezbędnych pakietów wszystko wróciło do normy.


To rozwiązanie uaktualniające może mieć własne problemy . Ponieważ php ewoluował całkiem sporo, oprogramowanie może się zepsuć w niewyobrażalny sposób. Tak więc, mimo że podążyłem tą ścieżką, możesz chcieć dłużej zachować wersję, którą lubisz.

Na szczęście wydaje się, że jest na to dobry sposób , jak opisano na stronie The Customize Windows:

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

Choć może to być lepsze rozwiązanie, nie próbowałem tego. Oczekuję, że następne kilka dni powie mi, czy powinienem.


1

W moim przypadku php-fpm wcale nie działało, więc musiałem tylko uruchomić usługę 😂

service php7.3-fpm start
#on ubuntu 18.04

1

Miałem podobny błąd.

Wszystkie rekomendacje nie pomogły.

Jedyne zastępcze dane www z nginx pomogły:

$ 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

Hej @Alexander, musisz zmienić polecenie właściciela na nginx, używając komendy chown. To bardzo mi pomogło.
Pratik Ghela

0

Aby dodać, w CentOS (i prawdopodobnie w Red Hat i Fedorze) plik do zmiany uprawnień to:

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


0

Kilka razy zmieniłem system operacyjny na moim serwerze, starając się uzyskać najwygodniejszy system.

Kiedyś działało bardzo dobrze przez większość czasu, ale w końcu dostałem ten błąd bramki 502.

Korzystam z php fpm dla każdego konta zamiast tego samego dla wszystkich. Więc jeśli jedna z nich ulegnie awarii, przynajmniej inne aplikacje będą nadal działać.

Kiedyś miałem dane użytkowników i grup www. Ale zmieniło się to w moim Debianie 8 z najnowszym Nginx 1.8 i php5-fpm.

Domyślnym użytkownikiem jest nginx, podobnie jak grupa. Aby być tego pewnym, najlepszym sposobem jest sprawdzenie plików / etc / group i / etc / passwd. Nie mogą kłamać.

To tam odkryłem, że teraz mam nginx zarówno w danych www, jak i nie.

Może to może pomóc niektórym osobom nadal próbować dowiedzieć się, dlaczego komunikat o błędzie wciąż się pojawia.

To zadziałało dla mnie.


0

Dla tych, którzy próbowali wszystkiego w tym wątku i nadal utknęli: to rozwiązało mój problem. Zaktualizowałem /usr/local/nginx/conf/nginx.conf

  1. Odkomentuj powiedzenie linii user

  2. spraw, www-dataaby stało się:user www-data;

  3. Zapisz (wymagany dostęp root)

  4. Uruchom ponownie nginx


0

Jeśli masz deklaracje

pid = /run/php-fpm.pid

i

Listen = /run/php-fpm.pid

w różnych plikach konfiguracyjnych, root będzie właścicielem tego pliku.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.