wsgi nginx error: permission denied beim herstellen einer Verbindung zum upstream

Scheint es viele Fragen auf StackOverflow, aber leider nichts für mich gearbeitet hat.

Ich bin immer ein 502 bad gateway nginx, und die folgenden Protokolle: connect() to ...myproject.sock failed (13: Permission denied) while connecting to upstream

Ich bin mit wsgi und nginx auf ubuntu, und ich habe nach dieser guide von Digital Ocean. Ich anscheinend konfiguriert wsgi richtig seit uwsgi -s myproject.sock --http 0.0.0.0:8000 --module app --callable app gearbeitet, aber ich bekomme immer wieder die nginx permission denied Fehler und ich habe keine Ahnung, warum:

Nach kommen über diese Frage und dieser andere, ich habe die .ini - Datei und fügte die chown-socket, chmod-socket, uid und gid Parameter (habe auch versucht nur die Einstellung der ersten beiden, entweder oder, und ein paar verschiedene Einstellungen für die Zugriffsrechte, --und sogar die meisten permissive hat nicht funktioniert).

Dieser schien vielversprechend, aber ich glaube nicht, dass selinux ist installiert auf meinem Ubuntu (läuft sudo apt-get remove selinux gibt "Paket" selinux "ist nicht installiert, wird also auch nicht entfernt" und find /-name "selinux" nicht alles zeigen). Nur für den Fall, obwohl, ich habe versucht, was dieser Beitrag empfohlen, da gut. Deinstallieren apparmor (sudo apt-get install apparmor) hat nicht funktioniert.

Jedes mal, wenn ich eine änderung vornehmen, ich Lauf sudo service nginx restart, aber ich sehe nur die 502 Gateway Fehler (und die Erlaubnis verweigert " - Fehler, wenn ich die logs).

Dies ist mein nginx Konfigurationsdatei:

server {
    listen 80;
    server_name 104.131.110.156;

    location /{
        include uwsgi_params;
        uwsgi_pass unix:/home/user/myproject/web_server/myproject.sock;
    }
}

.conf Datei:

description "uWSGI server instance configured to serve myproject"

start on runlevel [2345]
stop on runlevel [!2345]

setuid user
setgid www-data

env PATH=/root/.virtualenvs/my-env/bin
chdir /home/user/myproject/web_server
exec uwsgi --ini /home/user/myproject/web_server/myproject.ini

.ini Datei:

[uwsgi]
module = wsgi

master = true
processes = 5

socket = /home/user/myproject/web_server/myproject.sock
chown-socket=www-data:www-data
chmod-socket = 664
uid = www-data
gid = www-data

vacuum = true
die-on-term = true

(Wenn es hilft, das sind die specs von meinem Digital Ocean machine: Linux 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux)

Bitte lassen Sie mich wissen, wenn es etwas gibt, was ich tun kann, und ich danke Ihnen sehr viel.

Versuchen Sie die socket in /tmp. Sie könnten immer Zugriff verweigert wenn der nginx-user hat keine Berechtigungen zum auflisten eines der Verzeichnisse in den socket-Pfad. Es muss Berechtigungen für /home/user /home/user/myproject, etc
Vielen Dank für die Beantwortung! Leider, obwohl, gleicher Fehler: connect() to unix:/tmp/coaster.sock failed (13: Permission denied) while connecting to upstream
Ziemlich sicher, dass nginx läuft als www-data auf Ubuntu, aber durchaus einen Blick Wert... Was macht der /etc/nginx.conf sagen, dass nginx läuft? Auch, was passiert, wenn Sie php-fpm verwenden einen tcp-socket, wie die Adresse 127.0.0.1:9000?
Ja, ich denke, es läuft wie www-data. Ich dachte, dass es vielleicht ein problem mit den Berechtigungen, so wechselte ich den Besitzer der Verzeichnisse unter user/ zu den www-data Benutzer durch den Aufruf sudo chown www-data:www-data DIRNAME aber, auch nach dem Neustart der server und nginx, ich bekomme immer noch den gleichen Fehler. Ich bin auch nginx als root aus, da rufe ich sudo service nginx restart Weile auf meinem root-account. Und ich bin nicht mit PHP, aber Kolben + WSGI, also ich weiß nicht, ob das gilt...
Versuchen Sie, die TCP verwenden, statt unix-socket, der in Ihrem Fall ist es --socket 127.0.0.1:3031 argument und uwsgi_pass 127.0.0.1:3031; in der nginx-Konfiguration. Es funktioniert eh besser.

InformationsquelleAutor aralar | 2015-04-26

  1. 7

    Ich folgte das tutorial durch und lief in das gleiche Problem. Nach ein bisschen von Versuch und Irrtum, werden die folgenden Schritte erlaubt mir zu laufen, uWSGI und nginx erfolgreich:

    Meine nginx.config Datei:

    server {
    listen 80;
    server_name localhost;

    location /{ try_files @yourapplication; }
    location @yourapplication; {
        include uwsgi_params;
        uwsgi_pass unix:/PATH_TO_PROJECT/PROJECT.sock;
    }
}

    Meine .ini Datei war nicht sehr gut funktioniert, so dass ich beschloss, um die Vorteile von uWSGI die umfangreichen Argumente, die verfügbar sind. Hier ist, was ich verwendet habe:

    uwsgi -s /PATH_TO_PROJECT/PROJECT.sock -w wsgi:app -H /PATH_TO_PROJECT/venv --http-processes=4 --chmod-socket=666 --master &

    Wo:

    -s /PATH_TO_PROJECT/PROJECT.sock = der Ort meiner .sock Datei

    -w wsgi:app = der Ort meiner wsgi.py Datei und app wird der name von meinem Kolben Objekt

    -H /PATH_TO_PROJECT/venv = der Ort meiner virtuellen Umgebung

    --http-processes=4 = die Anzahl der http Prozesse für uWSGI zu erstellen

    --chmod-socket=666 = die Berechtigungen, die zu setzen sind, auf der Buchse

    --master = uWSGI zu laufen, mit seiner master-Prozess-manager

    & = uWSGI im hintergrund

    Hoffe, das hilft!

    chmod-socket = 666 im ini Datei hat den trick für mich.

    InformationsquelleAutor brandorags

  2. 6

    Den Pfad: unix:/PATH_TO_PROJECT/PROJECT.sock platziert werden soll in /tmp diese Feste mein problem.

    nicht lösen problem immer sehen (link)[stackoverflow.com/questions/22272943/...

    InformationsquelleAutor JZ.

  3. 5

    Nachdem alle Ratschläge in diesem thread war ich noch immer Berechtigung Fehler. Die endlich fehlende Stück war zu korrigieren nginx user im /etc/nginx/nginx.conf Datei:

    # old: user  nginx;
user  www-data;
    FYI ubuntu trusty64 Benutzer, nginx ist bereits konfiguriert als www-data. Ich hoffe, Sie Lesen dies, und ich speicherte Sie 30 Sekunden, zu überprüfen.

    InformationsquelleAutor ChrisFreeman

  4. 4

    (13: Permission denied)

    Dies bedeutet, dass Nginx konnte keine Verbindung zu der uWSGI-Buchse aufgrund von Berechtigungen Problemen. In der Regel geschieht dies, wenn der socket erstellt wird, in einer eingeschränkten Umgebung, oder wenn die Berechtigungen falsch waren. Während der uWSGI-Prozess ist in der Lage, die socket-Datei, Nginx ist nicht auf ihn zugreifen.

    Dies kann passieren, wenn es begrenzte Berechtigungen an einem Punkt zwischen dem root-Verzeichnis (/) der socket-Datei. Wir sehen die Berechtigungen und der Besitz Werte der socket-Datei und alle seine übergeordneten Verzeichnisse durch die übergabe der absolute Pfad zu unserem socket-Datei, die namei Befehl:

    namei -nom /PATH_TO_YOUR_SOCKET_FILE/YOUR_SOCKET.sock

    Sollte die Ausgabe ähnlich wie diese (Ihr Fall könnte verschiedene Ordner name)

    f: /run/uwsgi/firstsite.sock
 drwxr-xr-x root  root     /
 drwxr-xr-x root  root     run
 drwxr-xr-x sammy www-data uwsgi
 srw-rw---- sammy www-data firstsite.sock

    Zeigt die Ausgabe der Berechtigungen der einzelnen directory-Komponenten. Suchen Sie in den Berechtigungen (erste Spalte), Eigentümer (zweite Spalte) und der Gruppe Besitzer (Dritte Spalte), können wir herausfinden, welche Art von Zugriff erlaubt ist, um die socket-Datei.

    Im obigen Beispiel, jedem der Verzeichnisse im Vorfeld der socket-Datei haben, die Welt Berechtigungen Lesen und ausführen (die Spalte Berechtigungen für die Verzeichnisse am Ende mit r-x anstelle von ---). Die www-data Gruppe hat die Gruppe Kontrolle über die Steckdose selbst. Mit diesen Einstellungen Nginx Prozess sollte in der Lage sein, um Zugriff auf den socket erfolgreich.

    Wenn eines der Verzeichnisse im Vorfeld der sockel sind nicht im Besitz der www-data Gruppe oder haben nicht die Welt die Berechtigung Lesen und ausführen, Nginx wird nicht in der Lage sein, um Zugriff auf den socket. In der Regel bedeutet dies, dass die Konfigurations-Dateien haben einen Fehler gemacht.

    Damit Sie dieses Problem beheben, sondern geben alle übergeordneten Ordner die Berechtigung diesen Befehl zu benutzen: 

    chmod 755 directory_name

    Ich weiß, es ist spät, aber um anderen zu helfen überwinden das Problem schneller, ich habe diese Antwort. Hoffe es hilft, viel Glück.

    InformationsquelleAutor DeFoG

  5. 1

    Wenn Sie getestet haben, alle Berechtigungen und ist es immer noch nicht funktioniert, dann vielleicht SELinux aktiviert ist, bewirkt dies, dass das gleiche Verhalten.

    Laufen getenforce und wenn das Ergebnis Enforcing dann wird das nicht helfen.

    Schnelle Lösung ist, um es zu deaktivieren, setenforce 0 aber ein Neustart erforderlich ist.

    InformationsquelleAutor oden

  6. 1

    Zusammenfassen, was andere gesagt haben, zu lösen permission denied Fehler in nginx (Sie können einen Blick in /var/log/nginx/error.log ist in der Regel aufgrund der folgenden:

    1. Sie schreiben .sock Datei an einem Ort nginx nicht über die Berechtigung
    2. SELinux ist das problem verursacht

    Zu lösen 1: Zuerst nicht schreiben .sock Datei auf /tmp wie hier vorgeschlagen server-Fehler-Antwort da die verschiedenen Dienste unterschiedliche /tmp in fedora. Sie können schreiben, an einem Ort wie ~/myproject/mysocket.sock. Die nginx-Benutzer müssen Zugriff auf unser Verzeichnis der Anwendung, um Zugriff auf die socket-Datei gibt. Standardmäßig CentOS sperrt jedes Benutzers home-Verzeichnis sehr restriktiv, so fügen wir die nginx Benutzer auf die Benutzergruppe, so dass wir können, öffnen Sie dann die mindestens erforderliche Berechtigungen für den Zugriff erteilen.

    Können Sie die nginx-Benutzer Ihre Benutzer-Gruppe mit dem folgenden Befehl. Ersetzen Sie Ihre eigenen Benutzernamen für den Benutzer in die Befehlszeile:

    sudo usermod -a -G $USER nginx

    Nun, wir können unsere Benutzer Gruppe Berechtigungen auf unserer home-Verzeichnis. Damit wird die Nginx-Prozess zu geben und den Zugriff auf Inhalte im:

    chmod 710 /path/to/project/dir

    Wenn die permission denied Fehler ist immer noch da:
    dann das hack sudo setenforce 0 wird den trick tun.

    InformationsquelleAutor chandresh

  7. 0

    Dies kann passieren, wenn der Benutzer www-data kann nicht über die Berechtigung zum erstellen neuer
    Steckdose im angegebenen Pfad, so verwenden Sie den root-Benutzer.
    Relpace Benutzer www-data auf root-user in der nginx.conf;

    ex: #nginx.conf
#user www-data;
user root;
worker_processes auto;
pid /var/run/nginx.pid;
.............
    Das ist brute-force-Methode selten eine gute Idee. Mein fix für ein ähnliches Problem wurde auf hinzufügen diese Zeile zu nginx.conf-Datei: user www-data www-data;

    InformationsquelleAutor Vicky Gupta

  8. 0

    Überprüfen Sie das Feld Benutzer in der ersten Zeile in der nginx.conf-Datei. Es ist standardmäßig www-data. Ändern Sie den Namen, um den Benutzer root in der nginx.conf-Datei, wenn Sie als root angemeldet sind.

    InformationsquelleAutor Faisal Julaidan

Schreibe einen Kommentar