Hilfe! Nach Upgrade von Leap 15.3 auf 15.4 liefert NGINX keine Seite mehr aus ("Access denied. ")

Hinweis: In dem Thema Hilfe! Nach Upgrade von Leap 15.3 auf 15.4 liefert NGINX keine Seite mehr aus ("Access denied. ") gibt es 3 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Hallo,


    auf 15.3 hatte ich eine funktionierende Konfiguration aus NGINX WebServer und PHP-FPM. Mehrer VHOSTS lieferten korrekt die Seiten aus.

    Nach dem Upgrade von 15.3 auf 15.4 erhalte ich ich auf allen meinen PHP Seiten ein "Access denied".


    Das Logfile /var/log/nginx/error.log sagt:


    2022/12/01 13:54:21 [error] 13#13: *524 FastCGI sent in stderr: "PHP message: PHP Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0Unable to open primary script: /srv/www/vhosts/<vhost>.de/index.php (Permission denied)" while reading response header from upstream, client: 216.244.66.200, server: <vhost>.de, request: "GET /index.php...


    Irgendetwas muss sich in 15.4 geändert haben, was diesen Fehler provoziert.


    Ich habe folgendes versucht:

    - Zugriffsrechte unterhalb /srv/www/vhosts/<vhost> geändert: chown nginx * -R und chgrp nginx * -R

    - Zugriffsrechte unterhalb /srv/www/vhosts/<vhost> voll erweitert: chmod 777 * -R

    - appArmor Service testweise gestoppt

    - Firewall testweise gestoppt


    Das Problem erscheint bei JEDEM PHP Zugriff.


    Gut ist: Der Reverse Proxy arbeitet zumindest wie vorher. Das funktioniert also noch. (NODE.JS Server der auf 127.0.0.1 Port 1337 läuft und vom NGNIX korrekt nach außen geleitet wird (https, Port 80).


    Hat jemand eine Idee was ich noch versuchen kann?

    Danke & Grüße

    Für den Inhalt des Beitrages 302835 haftet ausdrücklich der jeweilige Autor: hesr_45

  • Hallo hesr_45,

    das Problem hatte ich nach dem Update von 15.3 auf 15.4 auch. Nur reine HML-Seiten wurden noch ausgeliefert (hier vom apache).

    Es liegt an apparmor und einem unvollständigen (?) Profil php-fpm.

    Aktuell ist bei mir apparmor deaktiviert (auch keine gute Lösung).

    Für einen Test:

    Code
    systemctl stop apparmor.service
    aa-teardown    

    aa-teardown ist notwendig, da auch nach einem Stopp von apparmor die Regeln noch aktiv sind.

    Für den Inhalt des Beitrages 302838 haftet ausdrücklich der jeweilige Autor: Kieltux

  • *Vielen Dank!*

    Das war es. Da muss man erst mal drauf kommen, dass die Regeln trotz Stopps noch aktiv bleiben. ;)

    Für den Inhalt des Beitrages 302839 haftet ausdrücklich der jeweilige Autor: hesr_45

  • Dann bitte noch als erledigt markieren. Siehe meine Signatur .