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.
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.
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?
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.
Zu open_basedir, ja. Aber zu session.save_path? Laut Deinem Posting meint die Gallery X3, dass der
/var/lib/php/sessionswä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.
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.
Siehe mein Einstiegsbeitrag, da sieht alles gut aus.
Das habe ich schon probiert, mit allen drei verfügbaren Einstellungen, also leer und die Einträge mit {DOCROOT} und {WEBSPACEROOT} jeweils am Anfang. Der Fehler bleibt derselbe.
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:
/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/tmpWas übersehe ich?
Mit PHP 7.3 funktioniert es auch nicht.
Sorry für die späte Antwort, hier ist der Output von journalctl. Die Formatierung habe ich leider nicht anders hinbekommen, beim Copy&Paste sind die Zeilenumbrüche aus irgendeinem Grunde gestorben. Mit code-Tags steht dann alles in einer Zeile, also auch nicht besser.
-- Logs begin at Do 2017-04-06 13:15:29 CEST, end at Do 2017-04-06 13:17:47 CEST. --Apr 06 13:17:41 HOSTNAME systemd[1]: Stopping Docker Application Container Engine...-- Subject: Unit docker.service has begun shutting down-- Defined-By: systemd-- Support: http://lists.freedesktop.org/m…/listinfo/systemd-devel-- -- Unit docker.service has begun shutting down.Apr 06 13:17:41 HOSTNAME systemd[1]: Stopping Docker Socket for the API.-- Subject: Unit docker.socket has begun shutting down-- Defined-By: systemd-- Support: http://lists.freedesktop.org/m…/listinfo/systemd-devel-- -- Unit docker.socket has begun shutting down.Apr 06 13:17:41 HOSTNAME systemd[1]: Starting Docker Socket for the API.-- Subject: Unit docker.socket has begun with start-up-- Defined-By: systemd-- Support: http://lists.freedesktop.org/m…/listinfo/systemd-devel-- -- Unit docker.socket has begun starting up.Apr 06 13:17:41 HOSTNAME systemd[1]: Listening on Docker Socket for the API.-- Subject: Unit docker.socket has finished start-up-- Defined-By: systemd-- Support: http://lists.freedesktop.org/m…/listinfo/systemd-devel-- -- Unit docker.socket has finished starting up.-- -- The start-up result is done.Apr 06 13:17:41 HOSTNAME systemd[1]: Starting Docker Application Container Engine...-- Subject: Unit docker.service has begun with start-up-- Defined-By: systemd-- Support: http://lists.freedesktop.org/m…/listinfo/systemd-devel-- -- Unit docker.service has begun starting up.Apr 06 13:17:41 HOSTNAME systemd[1]: docker.service start request repeated too quickly, refusing to start.Apr 06 13:17:41 HOSTNAME systemd[1]: Failed to start Docker Application Container Engine.-- Subject: Unit docker.service has failed
Das habe ich jetzt auch getan, Kernel 4.9 läuft.
Leider will Docker jetzt nicht mehr starten.
sudo service docker start
Job for docker.service failed. See 'systemctl status docker.service' and 'journalctl -xn' for details.systemctl status docker.service
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled)
Active: failed (Result: exit-code) since So 2017-04-02 12:39:53 CEST; 5s ago
Docs: https://docs.docker.com
Process: 2779 ExecStart=/usr/bin/dockerd -H fd:// (code=exited, status=1/FAILURE)
Main PID: 2779 (code=exited, status=1/FAILURE)Moin. Ich habe genau dasselbe Problem.
Ich habe nun erstmal 4.9 installiert.
4.9 von was?
Vielen Dank schon mal.
