Fehler "open_basedir restriction in effect" im Log bei Netcup Managed Server

Liebes Forum,

ich habe diverse Contao-Managed-Installationen auf einem Netcup Managed-Server und habe massive Probleme mit voll-laufenden Log-Files.

Code:

---

Fehler: mod_fcgid: stderr: PHP Warning: is_file(): open_basedir restriction in effect. File(/httpdocs/domain.de/www/fe_page.html.twig) is not within the allowed path(s): (/var/www/vhosts/domain.de/:/tmp/:/var/lib/php/sessions) in /var/www/vhosts/domain.de/httpdocs/domain.de/www/vendor/twig/twig/src/Loader/FilesystemLoader.php on line 212

---

An und für sich funktionieren die Seiten bzw. Contao bis auf die o. g. Fehlermeldung einwandfrei.

Mein PHP-Setup:
- PHP 8.1
- open_basedir: {WEBSPACEROOT}{/}{:}{TMP}{/} (Standard)
- Dokumentenstamm: httpdocs/domain.de/www/public (zuvor /web)

Vielen Dank für Eure Unterstützung und liebe Grüße!
Tom

open_basedir solltest du entfernen.

Hallo Tom,

bei netcup umstellen auf sessions…

Siehe Wiki: https://github.com/contao/contao-manager/wiki/netcup

Auch wenn man die PHP-Version umstellt, muss man den richtigen Pfad kontrollieren.

Vielen Dank für Eure Antworten!

@Spooky: Ich kann open_basedir in Plesk auf "none" setzen. Geht aber glaube ich nur bei Netcup-Kunden mit Managed-Server. Ich dachte open_basedir sei für den Contao-Manager bzw. den Composer notwendig?!

@planepix: Die Variante mit "sessions" im Pfad hatte ich auch probiert, dabei kam es zu den gleichen Fehlern im Log...

Zitat:

---

Zitat von Spooky

open_basedir solltest du entfernen.

---

Das wäre sicher die beste Lösung, falls dir das auf einem managed Server möglich ist oder von der Technik von netcup durchgeführt wird. (Edit: Kannst du nach deiner letzten Beitrag. Also probieren. Benötigt wird das absolut nicht. Oder wenn, dann nur um vertrauliche oder sicherheitskritische Dateien auf dem Server vor dem Zugriff per PHP zu schützen)

Allerdings kommen mir die Pfade in der Meldung komisch vor.
/httpdocs/domain.de/www/fe_page.html.twig
Das ist doch ein absoluter Pfad oder ist das da auch chrooted?
Die anderen Pfade, insbesondere
/var/www/vhosts/domain.de/
sind aber ebenfalls absolut und sicher keine chroot Pfade.

Wenn beides echte absolute Pfade sind, dann ist der erste Pfad sicher nicht unterhalb des zweiten. Wahrscheinlich existiert der erste Pfad dann gar nicht, wo kommt der denn letztlich her?
Muss hier eventuell der Dokumentenstamm als absoluter Pfad angegeben werden? Also eventuell so?

/var/www/vhosts/domain.de/httpdocs/domain.de/www/public

Wirst du ggf vermutlich eh merken, nachdem du open_basedir deaktiviert hast, wenn im Log dann drinsteht, dass die Datei nicht gefunden werden kann.

Zitat:

---

Zitat von tab

Allerdings kommen mir die Pfade in der Meldung komisch vor.

---

Danke für den Hinweis tab!
Beim Eingangspost hatte ich an der PHP-Konfig für open_basedir eingestellt: {WEBSPACEROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions. Diese aus dem Netz recherchierte Einstellung passt aber wohl nur für Netcup-Webhosting-Kunden und nicht für den Managed-Server.

Vorher hatte ich die im Managed-Server hinterlegte Standardeinstellung: {WEBSPACEROOT}{/}{:}{TMP}{/}. Doch auch hier kommt es zu einer vergleichbaren Fehlermeldung:

Code:

---

mod_fcgid: stderr: PHP Warning: is_file(): open_basedir restriction in effect. File(/httpdocs/domain.de/www/vendor/contao/listing-bundle/src/Resources/contao/templates/info/mod_html.html.twig) is not within the allowed path(s): (/var/www/vhosts/domain.de/:/tmp/) in /var/www/vhosts/domain.de/httpdocs/domain.de/www/vendor/twig/twig/src/Loader/FilesystemLoader.php on line 212

---

Zum Vergleich nochmals obiger Fehler:

Code:

---

mod_fcgid: stderr: PHP Warning: is_file(): open_basedir restriction in effect. File(/httpdocs/domain.de/www/fe_page.html.twig) is not within the allowed path(s): (/var/www/vhosts/domain.de/:/tmp/:/var/lib/php/sessions) in /var/www/vhosts/domain.de/httpdocs/domain.de/www/vendor/twig/twig/src/Loader/FilesystemLoader.php on line 212

---

Zum Dokumetenstamm:
var/www/vhosts/domain.de/httpdocs/domain.de/www/public kann ich nicht als Dokumeantenstamm festlegen.

Ich habe mir nun damit beholfen, open_basedir zu deaktivieren - auch wenn mich gleichwohl interessiert hätte, warum es mit {WEBSPACEROOT}{/}{:}{TMP}{/} nicht klappt ;)

Vielen lieben Dank für Eure Unterstützung!

{WEBSPACEROOT} ist der DocumentRoot, also der web/ bzw. public/ Ordner deiner Contao Installation. Daher kommt es zu diesem Fehler, da ja auf Dateien außerhalb davon zugegriffen werden muss.

Zitat:

---

Zitat von Spooky

{WEBSPACEROOT} ist der DocumentRoot, also der web/ bzw. public/ Ordner deiner Contao Installation. Daher kommt es zu diesem Fehler, da ja auf Dateien außerhalb davon zugegriffen werden muss.

---

Ist das bei netcup Managed Servern so? Ich habe keinen, deswegen weiss ich es nicht. Aber soweit ich das am Rande mitbekommen habe im dortigen Forum, ist zumindest ein Managed Private Server im Wesentlichen eher ein Webhosting mit mehr Ressourcen, mit relativ wenig mehr Einstellungsmöglichkeiten als bei einem Webhosting. Größere Änderungen laufen dann über den Support, der diese dann durchführt oder eben auch nicht.
Und im Webhosting (ebenfalls Plesk) bedeutet {WEBSPACEROOT}, dass alles komplett freigegeben ist, was dem User gehört, das andere wäre {DOCROOT}

Anyway, ich glaube mich zu erinnern, dass @Spooky oder die Agentur bei netcup einen Managed Server hat oder hatte, er wird es also im Zweifel wissen. Wenn im Logfile kein Fehler auftaucht, dass er das twig-Template nicht finden kann, dann sollte jetzt eigentlich alles in Ordnung sein mit deaktiviertem open_basedir.

Ja stimmt, {WEBSPACEROOT} sollte eigentlich gehen.

Zitat:

---

Zitat von Spooky

Ja stimmt, {WEBSPACEROOT} sollte eigentlich gehen.

---

Hmm, hiesse das dann

Code:

---

/httpdocs/domain.de/www/vendor/contao/listing-bundle/src/Resources/contao/templates/info/mod_html.html.twig

---

wird hier von open_basedir als absoluter Pfad hergenommen, also nicht von chroot "umzurechnender" Pfad? Dann wäre natürlich klar, dass dieses File nicht innerhalb des {WEBSPACEROOT} liegt, nicht mal innerhalb von /var. Ebenso wäre es dann unwahrscheinlich, dass diese Datei überhaupt existiert. Aber wo kommt dann dieser absolute Pfad her, wer erzeugt den so aus den gegebenen Einstellungen? Besonders wichtig scheint die Datei ja zumindest im Moment nicht zu sein, wenn ansonsten trotzdem alles lief.

Das ist halt der realpath. Ich vermute der PHP Prozess läuft in einer chrooted Umgebung oder so und daher passt das dann nicht mehr.