PHP gibt "Access denied", Berechtigungsproblem?

[Uridium]

Hab den Überblick verloren, in welcher Datei war die Zeile nochmal?

In der gleichen... lass suchen.

 

[Photon]

Hoppla, hab's, danke! Der Socket hat sich tatsächlich im Dateisystem umbenannt!

 

[Uridium]

Das ist ja nur ein Test. Der Name muss sich im Pool und in der 'location' übereinstimmen. Was bereits so ist.
Es ging hierbei eher darum, dass das Log aktiviert wird, bzw. die Datei überhaupt beachtet wird. Was wohl der Fall ist....

 

[Photon]

Ja genau, die Datei an sich wird beachtet, aber der Log, der in ihr konfiguriert ist, wird nicht geschrieben... Es ist richtig mysteriös...

 

[Uridium]

Schau mal, ob das hier weiter hilft (die obere Config brauchst Du nicht, deine ist schon in Ordnung). Das mit dem 'log_errors = On' klingt wichtig. Irgendein Masterswitch funkt dazwischen.
https://serverfault.com/a/1134394

Und starte den nginx auch mal neu.

 

[Photon]

Ist "log_errors = On" wirklich wörtlich so gemeint und nicht das "php_admin_flag[log_errors] = on", das wir schon gesetzt haben?

edit: Ich habe die Konfiguration in php.ini auch mal ausprobiert. In error.log von nginx sind dann aber nur die schon bekannten Einträge drin:

2025/02/05 21:23:05 [error] 4267#4267: *1 FastCGI sent in stderr: "PHP message: PHP Warning:  PHP Request Startup: Failed to open stream: Permission denied in Unknown on line 0; Unable to open primary script: /usr/share/nginx/html/GibbonEduCore-InstallBundle/info.php (Permission denied)" while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm/php-fpm.sock:", host: "localhost:8000"

 

[Uridium]

Vermutlich machen die das gleiche. Die Zeile ist in der 'php.ini'.
Setz mal das Logging hoch von warn->info wie in #35 beschrieben (nginx config, post #1).

 

[Photon]

Ah stimmt, die ist schon drin!

Hab das Logging auf Info gesetzt, aber leider gibt es unverändert weder Warnungen noch Infos, nur die bisherigen Errors...

 

[Uridium]

Hast Du nginx neu gestartet?

 

[Photon]

Klar, hab ich! Kann man irgendwie erzwingen, dass Nginx ein Info-Meldung rausschickt, um das Logging zu überprüfen?

 

[Uridium]

[Info] sollte eigentlich von Haus aus sehr gesprächig sein.

 

[Photon]

Dann kann ich es mir nicht erklären... Soll der Eintrag in die Hauptkonfigurationsdatei oder in die, die in sites-enabled sitzt? Ich hab's in der Hauptkonfigurarationsdatei geschrieben (also "warn" mit "info" ersetzt).

 

[cx01]

Noch ne Idee: Mach mal "journalctl -f" und ruf dann die Webseite auf. Falls z. B. AppArmor das ganze blockieren sollte, taucht dort eventuell ein Event auf.

 

[Photon]

Oha, da ist was! Hier die Ausgabe:

Feb 06 00:09:10 photon-virtualbox kernel: audit: type=1400 audit(1738796950.466:185): apparmor="DENIED" operation="open" profile="php-fpm" name="/usr/share/nginx/html/GibbonEduCore-InstallBundle/info.php" pid=4226 comm="php-fpm" requested_mask="r" denied_mask="r" fsuid=33 ouid=33
Feb 06 00:09:10 photon-virtualbox kernel: audit: type=1400 audit(1738796950.466:186): apparmor="DENIED" operation="open" profile="php-fpm" name="/var/log/fpm-php.www.log" pid=4226 comm="php-fpm" requested_mask="ac" denied_mask="ac" fsuid=33 ouid=33

edit: Und mit

aa-disable /etc/apparmor.d/php-fpm

ist das Problem nun auch gelöst: https://forum.manjaro.org/t/php-fpm-apparmor-denied-open/173819 Endlich!

Nochmals danke an alle für die tolle Unterstützung!!

 

[Photon]

Nun haben wir offenbar irgendwas bei den Pfaden verstellt und wenn ich /index.php aufrufe, wird auf /installer/installer.php weitergeleitet, im Log taucht aber /installer/installer/installer.php auf (der Unterordner taucht im Pfad also doppelt auf), die nicht gefunden wird mit "No input file specified". Es ist zum Mäusemelken...

 

[qiller]

Läuft das denn auch sauber über Port 8000? Nicht das er auf Port 80 wechselt und in dem anderen vhost landet, der ja nen anderes document-root hat. Eigentlich würde ich sogar davon abraten, den Port 8000 vHost als Unterverzeichnis in einem schon vorhandenen vHost zu installieren. Ich installier sowas immer lieber parallel und nicht geschachtelt (also bei dir wäre das dann /usr/share/nginx/GibbonEduCore-InstallBundle). Aber da muss man auch entsprechend Berechtigungen festlegen, am besten mit nem extra Benutzer und extra php-fpm Pool. Wär dann schon die "advanced" Installation.

Aber ich bin bei nginx nicht so zu hause, von daher tippe ich mal noch auf nen anderen Fehler. Kenne so ein Problem eigt. nur noch von inkorrekten Redirects, aber die hast du ja nicht am laufen, soweit ich das sehe konnte.

 

[Photon]

Doch, er bleibt im richtigen Port. Ich habe spaßeshalber den falschen Pfad angelegt und die Datei dorthin kopiert. Sie wird dann dort gefunden, kann aber nicht weitermachen, weil diverse andere PHP-Dateien, die mit relativen Pfaden eingebunden sind, nicht gefunden werden.

 

[Pummeluff]

Hab gestern auch schon überlegt, was das Problem sein könnte. Bin aber nicht auf AppArmor gekommen.

Mal etwas Hintergrunderklärung:
AppArmor prüft genau wie SELinux, ob die Dateien oder der Port in die vorgegebenen Werte für die Anwendung (Nginx) passen.

Webseiten liegen normalerweise bei Nginx auf Arch unter /srv/www. Weicht ein DocumentRoot (hier: usr/share/nginx/html/GibbonEduCore-InstallBundle/index.php) davon ab, dann grätscht AppArmor dazwischen.

Die Frage ist jetzt, wie GibbonEduCore dahin gekommen ist? Wenn du das selbst dahin kopiert hast, wäre als Verzeichnis wohl /srv/www/GibbonEduCore besser gewesen. Hätte sein können, dass AppArmor da nicht gemeckert hätte.

Und beim Port: Da stimme ich qiller zu. Normalerweise legt man da einen VHost an und lässt die Anwendung dann ganz normal über Port 80/443 laufen.

 

[Photon]

Ich war auch etwas irritiert vom Pfad unter /usr, aber ich dachte, wenn nginx seine Beispieldatei index.html dort drin hat, kann es nicht falsch sein, andere Seiten auch dort reinzuschieben (also ja, ich war's, der das dort platziert hat). Falsch gedacht! Bei Debian war die Beispieldatei unter /var/www... und die Welt war noch in Ordnung...

Bezüglich Port: In der Hauptkonfiguration nginx.conf ist ja schon das Verzeichnis /usr/share/nginx/html als root für Port 80 festgelegt. Beißt sich das nicht, wenn in einer zweiten Konfiguration ein anderer root für den gleichen Port definiert ist? Was wird denn vom Server als root verwendet? Oder meint ihr, ich sollte den server-Block in nginx.conf auskommentieren und dann beißt sich da nichts und Gibbon kriegt Port 80?

 

[qiller]

Beißt sich das nicht, wenn in einer zweiten Konfiguration ein anderer root für den gleichen Port definiert ist?

Achso ja, das beißt sich natürlich spätestens dann, wenn du denselben servername vergibst (bei dir ja "localhost"). Für vHosts braucht man immer eine Trennung, entweder auf IP-Adress-Basis, Portnummer oder Servername/FQDN. Letzteres muss dann auch richtig über DNS/hosts-file aufgelöst werden können.