X3 (photo.gallery) meldet open_basedir-Fehler

  • Ich scheitere leider daran, die Galeriesoftware X3 (photo.gallery) auf meinem Webhosting 2000 SE de a1 WEB in Betrieb zu nehmen.


    Ich hab eine Subdomain erzeugt und PHP 7.4 für diese aktiviert. Folgende Fehlermeldung wirft der Installer:


    PHP session.save-path directory is blocked by open_basedir. Your server session.save_path is set to /var/lib/php/sessions but this directory is not within your open_basedir allowed paths. If you can't login to your X3 panel, it means X3 can't save the login-session, in which case you need to contact your host.


    Das trifft auch zu, ich kann mich wirklich nicht einloggen.


    Folgenden Output liefert phpinfo() für open_basedir:


    Code
    1. /var/www/vhosts/hostingxxxxxx.asdf.netcup.net/httpdocs/domain.tld/:/tmp/:/var/lib/php5/sessions:/var/lib/php/sessions:/var/www/vhosts/hostingxxxxxx.asdf.netcup.net/tmp


    Was übersehe ich?


    Mit PHP 7.3 funktioniert es auch nicht.

  • Im CCP einloggen, die Lupe links von „Webhosting 1000 SE“ anklicken, in der Übersicht auf „Auto-Login Web“ klicken, dann in der Sektion für die entsprechende Domain im WCP/Plesk auf PHP-Einstellungen gehen und dort in der leeren Auswahlliste bei „open_basedir“ eine Auswahl treffen:

    Z.B.:

    pasted-from-clipboard.png



    Übernehmen und OK. Nach einer Weile sollte es klappen.

  • Hmm, ich meine mich zu erinnern, dass session.save_path früher zumindest per Default auf /var/lib/php5/sessions gestanden hat. Sollte eigentlich nichts machen, weil beide Pfade /var/lib/php/sessions und /var/lib/php5/sessions im open_basedir drin sind. Hat mich halt immerein wenig erheitert, dass meine PHP 7.2 sessions in /var/lib/php5/sessions landet. Aber es hat funktioniert, deswegen habe ich da nicht lang rumprobiert. Aber, was wäre, wenn der PHP-User in /var/lib/php/sessions zum Beispiel keine Schreibrechte hätte oder noch extremer, der Pfad gar nicht existiert? Würde eine durchschnittliche Galeriesoftware auch wirklich korrekt prüfen, warum sie jetzt hier nicht schreiben darf? Oder würde sie einfach sagen: Ich darf nicht schreiben, wird wohl open_basedir sein?


    Ist zwar weit hergeholt, aber ansonsten dürfte das hier im Thread beschriebene ja eigentlich gar nicht passieren können.

  • Siehe mein Einstiegsbeitrag, da sieht alles gut aus.

    Zu open_basedir, ja. Aber zu session.save_path? Laut Deinem Posting meint die Gallery X3, dass der /var/lib/php/sessions wäre - aber glaubst Du ihr und dem Plesk das auch? Hast Du auch nach den Änderungen „Übernehmen“ geklickt?


    Wenn es so immer noch nicht klappt, wirst Du Dich an den Support wenden müssen - nur bin ich nicht sicher, ob der helfen kann, wenn die Werte laut phpinfo stimmen. Da scheint es mir doch eher an der Gallery X3 zu liegen.


    Aber, was wäre, wenn der PHP-User in /var/lib/php/sessions zum Beispiel keine Schreibrechte hätte oder noch extremer, der Pfad gar nicht existiert? Würde eine durchschnittliche Galeriesoftware auch wirklich korrekt prüfen, warum sie jetzt hier nicht schreiben darf? Oder würde sie einfach sagen: Ich darf nicht schreiben, wird wohl open_basedir sein?

    Bei mir im Chroot selbst gibt es den Pfad jedenfalls nicht. Auf dem Server gibt es sie wohl doch. Diesem Verdacht könnte der Support schon einmal nachgehen.

  • Hmm, ich meine mich zu erinnern, dass session.save_path früher zumindest per Default auf /var/lib/php5/sessions gestanden hat. Sollte eigentlich nichts machen, weil beide Pfade /var/lib/php/sessions und /var/lib/php5/sessions im open_basedir drin sind. Hat mich halt immerein wenig erheitert, dass meine PHP 7.2 sessions in /var/lib/php5/sessions landet. Aber es hat funktioniert, deswegen habe ich da nicht lang rumprobiert. Aber, was wäre, wenn der PHP-User in /var/lib/php/sessions zum Beispiel keine Schreibrechte hätte oder noch extremer, der Pfad gar nicht existiert? Würde eine durchschnittliche Galeriesoftware auch wirklich korrekt prüfen, warum sie jetzt hier nicht schreiben darf? Oder würde sie einfach sagen: Ich darf nicht schreiben, wird wohl open_basedir sein?


    Ist zwar weit hergeholt, aber ansonsten dürfte das hier im Thread beschriebene ja eigentlich gar nicht passieren können.

    So was in der Art vermute ich mittlerweile auch, ja. Ich werde wohl den netcup-Support mal damit konfrontieren.

  • Zu open_basedir, ja. Aber zu session.save_path? Laut Deinem Posting meint die Gallery X3, dass der /var/lib/php/sessions wäre - aber glaubst Du ihr und dem Plesk das auch? Hast Du auch nach den Änderungen „Übernehmen“ geklickt?


    Sorry, ja, auch die Variable ist laut phpinfo() korrekt gesetzt.


    Ich hab parallel dazu auch im Forum von X3 mal einen Post aufgemacht, mal schauen, ob da was kommt. Den Support von netcup werde ich aber auch noch mal kontaktieren. Vielleicht liegt es ja wirklich an mangelnden Schreibrechten, wie schon tab schrieb.

  • Würde eine durchschnittliche Galeriesoftware auch wirklich korrekt prüfen, warum sie jetzt hier nicht schreiben darf? Oder würde sie einfach sagen: Ich darf nicht schreiben, wird wohl open_basedir sein?


    Ist zwar weit hergeholt, aber ansonsten dürfte das hier im Thread beschriebene ja eigentlich gar nicht passieren können.

    Dazu noch mal: die Fehlermeldung klingt schon ziemlich spezifisch. Da ich aber nicht in den Code reingeschaut habe, weiß ich natürlich auch nicht, was an der Stelle genau passiert.


    PHP session.save-path directory is blocked by open_basedir. Your server session.save_path is set to /var/lib/php/sessions but this directory is not within your open_basedir allowed paths. If you can't login to your X3 panel, it means X3 can't save the login-session, in which case you need to contact your host.

  • Wäre ja wohl einfach zu testen mit einem kleinen Skript. Das ist dann meist auch überzeugender, weil leicht nachvollziehbar, als wenn ein komplexes System das behauptet.

    Bestimmt, wenn ich wüsste, was da genau geprüft wird. Die Variablen auszulesen und darauf zu prüfen, ob open_basedir session.save_path enthält ist simpel, aber auch unnötig, da phpinfo() das ja bestätigt. Oder sehe ich das falsch?

  • Workaround: Ist es eventuell möglich, sessions in der Datenbank zu speichern, statt im Filesystem?

    Ich wüsste nicht, wie. Ich komme gar nicht erst so weit, dass ich mit der Software arbeiten könnte. Die Warnmeldung taucht direkt nach der Durchführung der Installation auf, ein Login ist nicht möglich. Im Installationsverzeichnis befinden sich natürlich haufenweise Dateien, aber da ich die Anwendung bisher auch nicht kenne, wüsste ich nicht mal, wo ich mit der Suche anfangen sollte.


    Warten wir mal ab, was Hersteller- und netcup-Support so zu sagen haben.


    Vielen Dank erst Mal für die vielen Hinweise.

  • Ich wüsste nicht, wie. Ich komme gar nicht erst so weit, dass ich mit der Software arbeiten könnte.

    Bei etlichen PHP-Anwendungen kann man das in der entsprechenden Config (config.inc.php, settings.php oder so ähnlich) definieren. Die Datenbankschemata sind meist bereits vorhanden. Im Source von X3 finde ich auf die Schnelle aber nichts.


    Ein weiterer Workaround wäre dieser hier: https://www.php.net/manual/en/function.session-save-path.php - Kommentar Nr. 51.


    Da werden die Sessions manuell in ein Session-Verzeichnis überhalb des Documentroots - aber innerhalb Deines Chroots gelegt. Es bietet sich $WEBSPACEROOT/tmp dafür an, das ebenfalls in open_basedir liegt.


    Bis der Support das etwaige Schreibrechteproblem gelöst hat, könnte man das in Erwägung ziehen. Aber bitte mit Vorsicht!

  • Eine Änderung auf /var/lib/php5/sessions brachte den gewünschten Erfolg. Das hatte ich zwischendurch schon mal aktiviert, aber wohl nicht lange genug gewartet. Warum das so ist, hat mir der Support nicht mitgeteilt, aber jetzt funktioniert es.


    Euch allen vielen Dank für die vielen Kommentare.

  • Ich hatte heute ebenfalls das Problem, dass seit dem Abspeichern der PHP-Einstellungen (Umstellen von PHP 7.2 auf 7.4) für eine Domain besagtes open_basedir-Problem auftrat. Die Einstellungen auf die vorherigen Werte zurücksetzen brachte keine Linderung - wohl aber das Umstellen auf /var/lib/php5/sessions (bisher nie verwendet!) . Von daher scheint es tatsächlich, als wäre da gerade ein kleiner Bug...

  • So, jetzt habe ich genug für heute. Man sollte wissen, wann man aufhören muss. Wollte "mal eben" eine Nextcloud aufsetzen auf einem bisher unbenutzten Webhosting 8000. Zum einen stimmt da wohl wirklich einiges nicht und es wird zumindest der session.save_path scheinbar übernommen, steht dann aber anders in der phpinfo. Dann war ich noch so blöd und habe per SSH den Nextcloud-Installer setup-nextcloud.php vermeintlich ins document root geladen, was ich auch noch persönlich per SSH angelegt hatte. Beim Aufruf 404. 10 Minuten lang habe ich geglaubt, dass auch das document root nicht richtig gesetzt wäre. Dann habe ich gemerkt, dass ich per SSH in meinem alten Webhosting 8000 unterwegs war ;(. Also war 404 schon korrekt und im Document Root liegt die "Hier ensteht eine neue Webseite" Datei drin. Nääh, für heute ist Schluss. Jetzt schaue ich noch kurz in den Adventskalender und dann ab ins Bett. Muss nur nochmal kurz das Türschild kontrollieren, ob ich auch in der richtigen Wohnung bin :rolleyes:. Wie hiess es mal so schön in einer Radio-Comedy: "Nächste Woche ist auch noch ein Tag".