HostEurope: Unable to write to the temporary system directory

**sr-tag** · 21.02.2022, 12:56

Hallo Zusammen ich bin der, der das aktuell im Slack-Chat besprochen hat.

Der erste funktionierende Lösungsansatz von @ausi ist, wenn man im contao-manager Verzeichnis eine php.ini Datei mit folgendem Inhalt anlegt ...

Code:

sys_temp_dir=/is/htdocs/user_tmp/wpxxxx_xxxx

... und dann den temp-Pfad der auch per sys_get_temp_dir() zurückgegeben wird dort einträgt.

Nach einem Browser-Fenster-Reload läuft mein contao-manager dann auch durch.

Gruß Sven und Danke an alle die mir bei der Lösungsfindung geholfen haben.

Übrigens: Ich hab meine Unterhaltung mit dem Support auch noch nicht beendet

**steamchatter** · 21.02.2022, 13:07

Jetzt kam die Antwort:

"Ihr Skript ruft hier PHP aus dem Ordner /usr/bin/php7.4 auf, dieser Aufruf ntuzt die Umgebungsvariablen für PHP über die Kommandozeile (CLI) anstelle der Variablen für den Aufruf über den Apache auf. Für die Kommandozeile ist als
sys_temp_dir /tmp hinterlegt, da es sich um ein Wirtssystem im Sharedhosting Bereich mit diversen Kunden mit jeweils eigenem Paketdefiniertem User-Tmp-Verzeichnis (in Ihrem Fall /is/htdocs/user_tmp/wp1182832_G3C6KLLLE9/) handelt.

Uns sind die Probleme mit der aktuellen Version des Contao Managers auf Sharedhosting Systemen bekannt, allerdings wurde unsererseits keine Änderung and der Paketkonfiguration vorgenommen. Die Ursache scheint hier in Änderungen der Art und Weise, wie der Contao Manager arbeitet, zu liegen. Auch tritt der Fehler nur im Bereich der Webhosting Pakete, also im Shared Hosting Bereich auf. In diesem Bereich haben die Pakete keine eigene CLI-Instanz, weswegen auch der SSH-Zugriff per SSH-Proxy geschieht, um die Sicherheit der Kundendaten zu gewährleisten. Da es sich hier um Shared Hosting Pakete handelt, können wir für Kommandozeilenoperationen weder den Zugriff auf /tmp freigeben (alle Kunden auf dem Wirtssystem würde hier hineischreiben), noch den Wert für sys_temp_dir auf Serverebene ändern (da auch hierdurch alle Kunden des Wirtssystems dasselbe Verzeichnis als temp_dir für PHP-Operationen auf der Kommandozeile nutzen würden).

Als Workaround können wir daher derzeit nur einen Wechsel von Webhosting- in den Webserverbereich oder die Verwendung einer älteren Contao Manager Version empfehlen."

Was tun?

**uwe_hoop** · 21.02.2022, 13:18

Das Hosteurope-Problem trat hier auch letzten Dienstag auf ca. 10 Installationen im Shared Hosting betroffen. Heute dann die Antwort des Supports auf die Nachfrage und Schilderung des Fehlers im Manager:

---
Sowohl für das Apache PHP Modul als auch den PHP Interpreter auf der CLI ist open_basedir bereits auf "no value" gesetzt. Warum der Contao Manager seit dem letzten Update keinen Zugriff mehr auf das für das jeweilige Shared Hosting Paket eingerichtete temp-Verzeichnis hat, können wir leider nicht sagen. Auch können wir keine Lösung im Shared Hosting Bereich anbieten. Auf unseren Webserverpaketen mit eigener CLI ist die Nutzung des aktuellen Contao-Managers jadoch möglich. Als Workaround können wir daher derzeit nur einen Wechsel von Webhosting- in den Webserverbereich oder die Verwendung einer älteren Contao Manager Version empfehlen.
Wir bedauern, Ihnen keine positive Rückmeldung geben zu können. Sollten Sie noch weitere Fragen haben, stehen wir Ihnen natürlich jederzeit gerne zur Verfügung.
---

Ich habe kein Interesse an dieser Upselling-Politik teilzunehmen und wäre sehr an einem offiziellen Workaround seitens der Contao-Community interessiert.

**Spooky** · 21.02.2022, 13:18

Zitat von steamchatter

Was tun?

HE antworten und ihnen sagen, dass sys_get_temp_dir() in PHP immer ein Verzeichnis liefern muss, auf das der PHP Prozess Schreibrechte hat. Egal wie das Script aufgerufen wurde. Das muss HE beheben.

**Spooky** · 21.02.2022, 13:23

Zitat von uwe_hoop

Warum der Contao Manager seit dem letzten Update keinen Zugriff mehr auf das für das jeweilige Shared Hosting Paket eingerichtete temp-Verzeichnis hat, können wir leider nicht sagen.

Siehe das Script weiter oben. HE hat vor kurzem hier eine Änderung gemacht, so wie es aussieht.

- - - Aktualisiert - - -

Zitat von uwe_hoop

und wäre sehr an einem offiziellen Workaround seitens der Contao-Community interessiert.

Siehe weiter oben: https://community.contao.org/de/show...l=1#post555327
Trotzdem sollte HE das beheben.

**tab** · 21.02.2022, 13:32

Ich würde das Anmieten eines dedicated Servers empfehlen

. Um etwas zu bekommen, das man anderswo im Shared Webhosting problemlos bekommt. Was für ein Webhosting-Paket ist denn das eigentlich bei HE? Hat man da SSH-Zugang? In der Featureliste sieht es nicht so aus und in die Antwort von HE interpretiere ich das jetzt auch mal so rein. Ansonsten klappt es vielleicht per Composer in der Konsole. oder es findet jemand einen Workaround.

Spannend finde ich freilich die Frage, ob bei HE wirklich nichts an der Konfiguration geändert wurde und warum das dann ggf seither funktioniert hat?!? So wie ich das auf Slack verstanden habe, wurde ja im Contao-Manager auch nichts geändert, was das jetzt neu auftretende Problem erklären könnte. Hmm.

**sr-tag** · 21.02.2022, 13:36

Zitat von tab

Ich würde das Anmieten eines dedicated Servers empfehlen

. Um etwas zu bekommen, das man anderswo im Shared Webhosting problemlos bekommt. Was für ein Webhosting-Paket ist denn das eigentlich bei HE? Hat man da SSH-Zugang? In der Featureliste sieht es nicht so aus und in die Antwort von HE interpretiere ich das jetzt auch mal so rein. Ansonsten klappt es vielleicht per Composer in der Konsole. oder es findet jemand einen Workaround.

Spannend finde ich freilich die Frage, ob bei HE wirklich nichts an der Konfiguration geändert wurde und warum das dann ggf seither funktioniert hat?!? So wie ich das auf Slack verstanden habe, wurde ja im Contao-Manager auch nichts geändert, was das jetzt neu auftretende Problem erklären könnte. Hmm.

ne das Basic-Paket hat weder ssh noch nen SSL (Let's Encrypt)

**steamchatter** · 21.02.2022, 13:36

Zitat von uwe_hoop

Ich habe kein Interesse an dieser Upselling-Politik teilzunehmen und wäre sehr an einem offiziellen Workaround seitens der Contao-Community interessiert.

Ich werde ausis Workaround testen, vielleicht kann ich damit leben.

**steamchatter** · 21.02.2022, 13:39

Zitat von sr-tag

ne das Basic-Paket hat weder ssh noch nen SSL (Let's Encrypt)

SSH gibts durchaus beim Basic-Paket von HE.

**uwe_hoop** · 21.02.2022, 13:54

Perfekt, workaround per php.ini funktioniert. Der tatsächliche Temp-Pfad kann einfach über eine phpinfo.php ermittelt und dann in die php.ini eingetragen werden.
Sollte sich seitens HE bei deren Serverkonfiguration wieder etwas ändern (habe erneut standardkonformes Verhalten nachgefragt), wird es hier gepostet.

**strich-sieben** · 21.02.2022, 14:00

Auf meine Beschwerde bei HE habe ich noch folgende Info erhalten:

Gerne habe ich bezüglich Ihrer Rückmeldung mit Contao Rücksprache mit unserer Systemadministration gehalten. Wir konnten keinen Fehler in unserer Konfiguration erkennen. Das "sys_temp_dir" wird korrekt zurückgegeben. Das können Sie auch aus unserer Beispiel PHP-Info entnehmen: http://php74.hosteurope-infos.de/phpinfo.php

Wert: sys_temp_dir
Local Value: /is/htdocs/user_tmp/wp1176167_NC82OQMVXM

Contao funktioniert auf unseren WebHosting Paketen nur, wenn der Cloudresolver genutzt wird. Die Nutzung von Composern ist erst ab den WebServer Paketen mit vollem SSH-Zugriff möglich.

Ich konnte das Problem in diesem Fall mit der php.ini von @ausi lösen, momentan läuft der CM durch

**tab** · 21.02.2022, 14:12

Na da sind wir aber mal froh, dass es doch einen Workaround gibt. So kann auch der Support noch was lernen.

**Spooky** · 21.02.2022, 14:57

Zitat von strich-sieben

Auf meine Beschwerde bei HE habe ich noch folgende Info erhalten:

Gerne habe ich bezüglich Ihrer Rückmeldung mit Contao Rücksprache mit unserer Systemadministration gehalten. Wir konnten keinen Fehler in unserer Konfiguration erkennen. Das "sys_temp_dir" wird korrekt zurückgegeben. Das können Sie auch aus unserer Beispiel PHP-Info entnehmen: http://php74.hosteurope-infos.de/phpinfo.php

Wert: sys_temp_dir
Local Value: /is/htdocs/user_tmp/wp1176167_NC82OQMVXM

Contao funktioniert auf unseren WebHosting Paketen nur, wenn der Cloudresolver genutzt wird. Die Nutzung von Composern ist erst ab den WebServer Paketen mit vollem SSH-Zugriff möglich.

Dann kannst du ja nochmal an den Support zurückschreiben, dass das sys_temp_dir eben nicht korrekt gesetzt wird (siehe Script) und dass das Problem nichts mit Contao, dem Contao Manager, dem Cloud Resolver oder Composer zu tun hat.

**sr-tag** · 22.02.2022, 08:48

Zitat von steamchatter

SSH gibts durchaus beim Basic-Paket von HE.

In dem Basis-Paket was mein Kunde hier hat aber nur als Zusatzleistung und nicht wie bei meinen Favorisierten Hostern als Let's Encrypt kostenlos inklusive. Und nur wenn man doch ein anderes Zertifikat haben will, kann man sich dann auch ein anderes dazu bestellen.

**Yangdoo** · 22.02.2022, 09:20

Vielen Dank an alle, bei mir hat der Workaround von @ausi auch funktioniert.

**sr-tag** · 22.02.2022, 09:20

Zitat von strich-sieben

Auf meine Beschwerde bei HE habe ich noch folgende Info erhalten:

Gerne habe ich bezüglich Ihrer Rückmeldung mit Contao Rücksprache mit unserer Systemadministration gehalten. Wir konnten keinen Fehler in unserer Konfiguration erkennen. Das "sys_temp_dir" wird korrekt zurückgegeben. Das können Sie auch aus unserer Beispiel PHP-Info entnehmen: http://php74.hosteurope-infos.de/phpinfo.php

Wert: sys_temp_dir
Local Value: /is/htdocs/user_tmp/wp1176167_NC82OQMVXM

Contao funktioniert auf unseren WebHosting Paketen nur, wenn der Cloudresolver genutzt wird. Die Nutzung von Composern ist erst ab den WebServer Paketen mit vollem SSH-Zugriff möglich.

Ich konnte das Problem in diesem Fall mit der php.ini von @ausi lösen, momentan läuft der CM durch

Denen gerne auch mal den Hinweis geben das sie nicht nur einfach den Befehl 'get_sys_temp_dir()' aufrufen sollen sondern diesen durch paththrue() aufrufen sollen:

Code:

passthru('/usr/bin/php7.4 -r \'var_dump(sys_get_temp_dir());\'');

Mir antworten sie jetzt nicht mehr.

aktuell habe ich das Script:

Code:

<?php
var_dump(sys_get_temp_dir());
passthru('/usr/bin/php7.4 -r \'var_dump(sys_get_temp_dir());\'');

file_put_contents($path = sys_get_temp_dir()."/".uniqid(), "test");
var_dump(file_get_contents($path));
passthru('/usr/bin/php7.4 -r \'file_put_contents($path = sys_get_temp_dir()."/".uniqid(), "test"); var_dump(file_get_contents($path));\'');

auch noch unter http://www.marcus-wilke.de/test-tempdir.php zum anschauen. Das lasse ich aber nicht ewig da. ist nur damit der Support sich das anschauen kann. Damit es aber zu eurer Supportanfrage passt würde ich empfehlen das Script in eurem Paket im web/-Verzeichnis als PHP-Datei anzulegen.

**steamchatter** · 22.02.2022, 09:41

Zitat von sr-tag

In dem Basis-Paket was mein Kunde hier hat aber nur als Zusatzleistung und nicht wie bei meinen Favorisierten Hostern als Let's Encrypt kostenlos inklusive. Und nur wenn man doch ein anderes Zertifikat haben will, kann man sich dann auch ein anderes dazu bestellen.

Ich habe den SSH-Zugang gemeint (den gibt es nach viel Hickhack seit ca. 2018), nicht das SSL-Zertifikat. Ja hier hab ich auch schon gefühlt 1000x angefragt, ob es denn nicht möglich sei, LetsEncrypt zur Verfügung zu stellen wie es viele andere Provider für beliebig viele Domains kostenlos anbieten. Aber da kam nie was zurück… naja das ist jetzt OT.

**strich-sieben** · 22.02.2022, 15:15

Zitat von sr-tag

Denen gerne auch mal den Hinweis geben das sie nicht nur einfach den Befehl 'get_sys_temp_dir()' aufrufen sollen sondern diesen durch paththrue() aufrufen sollen:

Code:

passthru('/usr/bin/php7.4 -r \'var_dump(sys_get_temp_dir());\'');

Mir antworten sie jetzt nicht mehr.

aktuell habe ich das Script:

Code:

<?php
var_dump(sys_get_temp_dir());
passthru('/usr/bin/php7.4 -r \'var_dump(sys_get_temp_dir());\'');

file_put_contents($path = sys_get_temp_dir()."/".uniqid(), "test");
var_dump(file_get_contents($path));
passthru('/usr/bin/php7.4 -r \'file_put_contents($path = sys_get_temp_dir()."/".uniqid(), "test"); var_dump(file_get_contents($path));\'');

auch noch unter http://www.marcus-wilke.de/test-tempdir.php zum anschauen. Das lasse ich aber nicht ewig da. ist nur damit der Support sich das anschauen kann. Damit es aber zu eurer Supportanfrage passt würde ich empfehlen das Script in eurem Paket im web/-Verzeichnis als PHP-Datei anzulegen.

Habe nochmal ne Antwort bekommen:

"Dass einzelne Content-Management-Systeme oder Webanwendungen eine Anpassung an die jeweilige Hosting-Umgebung erfordern, ist nicht ungewöhnlich. Gerne nehmen wir Ihr Feedback mit."

Go Daddy, Go ..........................

**1gluecksgriff** · 22.02.2022, 15:16

An welcher stelle platziert ihr die php.ini datei mit dem "sys_temp_dir=//is/htdocs/user_tmp/wpXXXX/?

in folgenden Verzeichnissen haben wir es schon versucht:
/www
/www/contao-manager
/www/web

leider ohne Erfolg der Contao Manager will nicht mehr starten. Bei uns sind leider auch eine Menge Kunden betroffen.

**Spooky** · 22.02.2022, 15:18

Zitat von strich-sieben

Habe nochmal ne Antwort bekommen:

"Dass einzelne Content-Management-Systeme oder Webanwendungen eine Anpassung an die jeweilige Hosting-Umgebung erfordern, ist nicht ungewöhnlich. Gerne nehmen wir Ihr Feedback mit."

Antworte ihnen: Es geht aber nicht um CMS oder sonstige Webanwendungen, sondern um reine PHP Funktionalitäten. Siehe das Script.

**steamchatter** · 22.02.2022, 22:05

Hier nochmal eine vollständige Antwort von Host Europe. Wie zu erwarten wird @ausis Workaround zum Standard:

Leider ist, wie bereits von unserem Herrn XXXX beschrieben, die
Konfiguration, bei den Shared Hosting Paketen keinen Zugriff auf das Temp
Verzeichnis des Betriebssystems zu ermöglichen, schon allein aus
Datenschutzgründen unumgänglich. Andernfalls könnten dort abgelegten Daten
von anderen Kunden eingesehen werden.

Wie Sie möglicherweise jedoch bereits wissen, gibt es einen Workaround für das
Verhalten des Contao Managers:

Bitte legen Sie eine php.ini Datei im Contao Manager-Verzeichnis mit folgendem
Inhalt an:

sys_temp_dir=/is/htdocs/user_tmp/wpxxxxx/

Bitte beachten Sie, dass sich der oben genannte Pfad auf auf das Temp
Verzeichnis für Ihre Webhosting Basic Paket mit der ID 1182832 bezieht und
natürlich für andere Pakete entsprechend angepasst werden muss.

Das User Temp Verzeichnis wird im KIS unter folgendem Pfad angezeigt:

Produktverwaltung - Webhosting - Konfigurieren - Allgemeines - Allgemeine
Informationen

Nach einem Neustarten des Managers sollte dieser wieder wie gewohnt
funktionieren.

Bei Rückfragen stehen wir Ihnen gerne zur Verfügung.

**tab** · 22.02.2022, 23:13

Das wird auch der Standard sein müssen, solange HostEuope an der augenblicklichen Systemkonfiguration festhält. Wenn es, aus welchen Gründen auch immer, tatsächlich so sein, dass eine Änderung dieses sys_temp_dir sich global auf alle Kunden auswirken würde und dass, aus welchen Gründen auch immer, deswegen jeder Kunde Zugriff auf die temporären Dateien aller anderen Kunden hätte, dann funktioniert freilich die an sich vernünftige Lösung mit einem geänderten sys_temp_dir, für jeden Kunden unterschiedlich, nicht.

Dann würde ich zwar mit Coyote Carlo sagen "Zurück zum Zeichenbrett", konfiguriert eure Webhostingserver so, dass jeder Kunden, ohne eine eigene php.ini zu benötigen, sein temporäres Verzeichnis benutzen kann. Aber solange das nicht so ist, geht es eben nicht ohne eigene php.ini. Da muss man ja direkt noch froh sein, dass eine eigene php.ini überhaupt funktioniert. Denn sys_temp_dir kann nun mal nur in einer php.ini gesetzt werden. Ich habe genügend Webhostings, wo eine eigene php.ini nicht funktioniert, bestenfalls eine .user.ini oder überhaupt nichts. Aber da besteht eben das Problem mit diesem temporären Verzeichnis nicht.

**Achim H.** · 23.02.2022, 16:39

Mit dem hier beschriebenen Workaround klappt es jetzt ...

**Spooky** · 23.02.2022, 16:45

Zitat von steamchatter

Hier nochmal eine vollständige Antwort von Host Europe. Wie zu erwarten wird @ausis Workaround zum Standard:

Du könntest an HE folgendes antworten:

Es geht auch nicht daraum Zugriff auf das Temp Verzeichnis des Betriebssystem zu erlangen. Es geht darum, dass in der aktuellen Konfiguration von PHP auf Host Europe kein korrektes Verzeichnis von der PHP Funktion sys_get_temp_dir() geliefert wird unter der Verwendung von passthru() (siehe Beispiel Script). HostEurope muss dafür sorgen, dass auch unter diesen Umständen das korrekte Verzeichnis geliefert wird.

**nicknack** · 01.03.2022, 10:38

Hallo,

ich habe seit gestern das gleiche Problem mit der Fehlermeldung. Ich habe eine php.ini in das gleiche Verzeichnis des contap-managers gelegt, allerdings bekomme ich immer noch die gleiche Fehlermeldung. Ich habe nur "sys_temp_dir=/is/htdocs/user_tmp/wpxxxx_xxxx" in der php.ini stehen. Gibt es sonst noch etwas zu beachten? Den contao-manager habe ich mehrfach neu gestartet und Cache geleert etc.
Danke und Grüße
David

**Spooky** · 01.03.2022, 10:44

Zitat von nicknack

Ich habe nur "sys_temp_dir=/is/htdocs/user_tmp/wpxxxx_xxxx" in der php.ini stehen. Gibt es sonst noch etwas zu beachten?

Den "xxxx_xxxx"-Teil hast du angepasst und nicht 1:1 übernommen?

**nicknack** · 01.03.2022, 11:11

Zitat von Spooky

Den "xxxx_xxxx"-Teil hast du angepasst und nicht 1:1 übernommen?

Ja, dort habe ich den Pfad übernommen, den mir die info.php Datei angezeigt hat.

**nicknack** · 01.03.2022, 11:13

Zitat von nicknack

Ja, dort habe ich den Pfad übernommen, den mir die info.php Datei angezeigt hat.

Ist momentan eine noch Subdomain, sollte aber keinen Unterschied machen oder? Die info.php ist ja im gleichen Verzeichnis wie der contao-manager.

**c-j-s** · 02.03.2022, 15:27

Hallo nicknack und andere Leidensgenossen:

nach einigen (sinnlosen) Stunden ausprobieren hat es bei mir mit folgender Lösung geklappt (HE, WebHosting Supreme mit MySQL 8.0 und PHP 8.0):

Zuerst eine info.php ins Verzeichnis /www/<DEIN_PFAD>/web geladen und über den Browser aufgerufen.

Dann eine Datei php.ini erstellt, mit folgendem Inhalt:

open_basedir = none
sys_temp_dir = /is/htdocs/user_tmp/wp12345678_XXXXXXXXXX
allow_url_fopen = 1

wobei /is/htdocs/user_tmp/wp12345678_XXXXXXXXXX durch die Info aus der Zeile sys_temp_dir aus dem Aufrufergebnis der info.php

und diese per FTP in die Ordner

/www/<DEIN_PFAD>/contao-manager
/www/<DEIN_PFAD>/web
/www/<DEIN_PFAD>

kopiert.

Danach erst hat es funktioniert.
Kann sein, dass man nicht alles braucht, was ich gemacht habe, aber ehrlich gesagt ist mir die Lust am Ausprobieren schon länger vergangen.
Danke aber an alle, die mich auf den richtigen Pfad gebracht haben!
LG
Christian

**contaowilli** · 12.03.2022, 12:03

Zitat von sr-tag

Hallo Zusammen ich bin der, der das aktuell im Slack-Chat besprochen hat.

Der erste funktionierende Lösungsansatz von @ausi ist, wenn man im contao-manager Verzeichnis eine php.ini Datei mit folgendem Inhalt anlegt ...

Code:

sys_temp_dir=/is/htdocs/user_tmp/wpxxxx_xxxx

... und dann den temp-Pfad der auch per sys_get_temp_dir() zurückgegeben wird dort einträgt.

Nach einem Browser-Fenster-Reload läuft mein contao-manager dann auch durch.

Gruß Sven und Danke an alle die mir bei der Lösungsfindung geholfen haben.

Übrigens: Ich hab meine Unterhaltung mit dem Support auch noch nicht beendet

Es ist doe "Mumpitz" , wenn ma bei HE irgendwelche php.ini `s schreiben muss damit es funktioniert. Was ich verstanden habe, ist, dass es hier wohl um ein Sicherheitsaspekt geht. Nur HE schiebt das Problem auf Contao und umgekehrt. Jetzt las ich von Spooky, dass HE vor kurzem was geändert hat....
Wie wird denn das Problem nun gehandhabt, egal von wem?
HE meint es muss beim istallieren des Contao Managers ein input-Feld erscheinen, damit der Installateur den richtigen TMP Pfad eingeben kann.

Von einer eigens erstellten php.ini sehe ich ab, da ich bei einem Umzug von HE weg immer die Dateien wieder löschen muss, die ich da vorher angelegt habe. (wer weiss wie viele das noch werden?) Außerdem fehlt mir da seitens HE der Schreibzugriff. HE will, denke ich, dass ein größeres Paket gebucht wird. Was ich mit den Problemen dort sehr sicher nicht machen werde. Allein die Preispolitik der SSL Zertifikate des Servers sind ein Hohn, wenn ich sie wo anders kostenlos bekomme. (Lets Encrypt)
Da ich des Öfteren Probleme mit HE habe, denke ich gerade an einen Serveranbieter hier im Ort nach. Ich hoffe nur dass ich die Arbeit etwas strecken kann und hier oder bei HE eine bessere Lösung gefunden wird.
Vielleicht kennt jemand einen Server wo es Wert ist mit Contao-Installationen hinzuziehen?

**tab** · 12.03.2022, 12:50

Zitat von contaowilli

Da ich des Öfteren Probleme mit HE habe, denke ich gerade an einen Serveranbieter hier im Ort nach. Ich hoffe nur dass ich die Arbeit etwas strecken kann und hier oder bei HE eine bessere Lösung gefunden wird.
Vielleicht kennt jemand einen Server wo es Wert ist mit Contao-Installationen hinzuziehen?

Ohne Anspruch auf Vollständigkeit, aus eigener Erfahrung, würde ich derzeit folgende Anbieter empfehlen: Hostingwerk, All-Inkl, Webgo
Den absolut perfekten Anbieter zu finden ist sicher schwierig, irgendeinen Pferdefuss wird es wohl immer geben, solange das Budget beschränkt ist.

Uberspace ist vermutlich immer noch empfehlenswert, aber ich habe dort derzeit keinen Webspace mehr aktiv, der letzte ist meinem teilweisen Umstieg auf vServer zum Opfer gefallen.
Netcup hat für mich derzeit zu viele Problemchen, um eine Empfehlung an jemanden auszusprechen, der von Problemen die Nase voll hat.

Webgo hat wohl auch seine Probleme, wie ich von anderen hier höre. Das mag dem großen Umzug in ein neues Rechenzentrum geschuldet sein oder wie auch immer. Aus eigener Erfahrung läuft aber mein CMS Power SSD Paket problemlos und auch mit meinen Kunden dort (Go-Paket Platin) gibt es derzeit keine Probleme. Auch das Update von Contao 4.9 auf 4.13 wird da problemlos verlaufen, habe ich natürlich schon längst vorab getestet.
All-Inkl (Premium) läuft bei mir auch meist problemlos.
Hostingwerk (Leo Feyer) wird eventuell doch einmal mit Contao auftretende Probleme sicher am ehesten lösen können.

**RoadRunner-HH** · 27.03.2022, 18:07

Hallo in die Runde,

nachdem ich seit gestern nach dem Auto-Update des Contao-Manager ebenfalls betroffen bin, habe ich durch Eure Tipps und den Workaround hier im Forum zumindest die Funktion herstellen können. Der Workaround funktioniert bei mir, mein Dank dafür an alle!

Ich hatte die Infos aus diesem Thread gleich zu Beginn bei der Support - Anfrage mitgeliefert (Fehlermeldung, Test-Script, Testergebnis, Ursache bei Verwendung von passthru).

Leider erhielt auch ich die gleiche Antwort des Host Europe Support. Da dies nicht mein Fachgebiet ist, fehlt mir hier leider die nötige Expertise, allerdings klingen die hier genannten Argumente von @spooky sehr plausibel und naheliegend.

Antwort des Host Europe Support:

Das Anliegen lässt sich leider nur über den Workaround lösen:

Bitte legen Sie eine php.ini Datei im Contao Manager-Verzeichnis mit folgendem Inhalt an:

PHP-Code:


sys_temp_dir=/is/htdocs/user_tmp/wpID_xy/

Bitte beachten Sie, dass sich der oben genannte Pfad auf auf das Temp Verzeichnis für Ihre Webhosting Basic Paket mit der ID bezieht und natürlich für andere Pakete entsprechend angepasst werden muss.

Das User Temp Verzeichnis wird im KIS unter folgendem Pfad angezeigt:

"Produktverwaltung - Webhosting - Konfigurieren - Allgemeines - Allgemeine Informationen"

Nach einem Neustarten des Managers sollte dieser wieder wie gewohnt funktionieren.

Leider ist unsere Konfiguration, bei den Shared Hosting Paketen keinen Zugriff auf das Temp Verzeichnis des Betriebssystems zu ermöglichen, schon allein aus
Datenschutzgründen unumgänglich. Andernfalls könnten dort abgelegten Daten von anderen Kunden eingesehen werden.

**tab** · 27.03.2022, 18:19

Ja, leider hat HE das eigentliche Problem immer noch nicht erkannt oder sie wollen es nicht erkennen. Niemand besteht darauf, auf das temporäre Verzeichnis des Betriebssystems zugreifen zu wollen. Letztlich sollte einfach bei jeder Verwendung von PHP, die überhaupt möglich ist, von HE (nicht vom Kunden!) ein beschreibbares temporäres Verzeichnis für PHP gesetzt werden. Beim "normalen" Webprozess machen sie es ja, also warum nicht einfach auch hier? Wenn man keines setzt, dann greift eben der Defaultwert, was letztlich dann das temporäre Verzeichnis des Betriebssystems ist.

**whitedrow** · 06.04.2022, 16:54

Moin,

ich habe auch das "HE-Problem".

Mit dem Workaround konnte ich eine Contao 4.13.1 Version unter PHP 8.0 installieren. Mit der aktuellen Contao Version geht's nicht mehr.

Das Ganze hat auch einen eigenen Thread, zu sehen hier:
https://community.contao.org/de/show...ehler&p=557385

Hier noch mal die Kurzform:
Installations Testreihe

Contao	PHP	open_basedir	sys_temp_dir	allow_url_fopen	Installation
4.9	7.4		gesetzt		Erfolgreich
4.9	8.0		gesetzt		Gescheitert
4.13	7.4		gesetzt		Erfolgreich
4.13	8.0		gesetzt		Gescheitert

Support zuckt irgendwie auch nicht mehr bei mir.

Gibt es vielleicht schon einen neuen Workaround?

**mlweb** · 06.04.2022, 22:08

Zitat von whitedrow

Support zuckt irgendwie auch nicht mehr bei mir.
Gibt es vielleicht schon einen neuen Workaround?

Wenn ich den Thread hier so verfolge und auch die Beiträge auf Slack zu diesem Thema, würde ich sagen nur Abstimmung mit den Füßen - also Hosterwechsel - lässt solche Provider gelegentlich aufwachen.

**tab** · 06.04.2022, 22:26

Ich würde einfach mal die phpinfo() Ausgabe der beiden PHP-Versionen mal akribisch vergleichen, da muss es ja Unterschiede geben. Eventuell ist die php.ini mit PHP 8.0 einfach nicht wirksam. Das müsste man dann ja sehen, wenn die in der php.ini gesetzten Werte da bei der entsprechenden Einstellung nicht auftauchen. Eventuell muss die Datei dort auch nicht php.ini heissen, sondern z.B. ".user.ini" oder "user.ini". Der entsprechende Name sollte bei "user_ini.filename" ersichtlich sein, Default ist wohl ".user.ini".

**whitedrow** · 08.04.2022, 00:11

Wenn ich ne "user.ini" benutze, kommt wieder der Hinweis:

Code:

PHP Kommandozeilen-Programm
Unable to write to the temporary system directory.

Der Contao-Manager bricht immer ab mit:

Code:

Notice: tempnam(): file created in the system's temporary directory in /is/htdocs/wpxxx_yyy/www/contaotest/contao4-13-php8-0/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php on line 684

Fatal error: Uncaught ValueError: Path cannot be empty in /is/htdocs/wpxxx_yyy/www/contaotest/contao4-13-php8-0/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php:692

Bin eher nicht so der PHP Mensch, aber könnte da nicht der Hund begraben liegen?
Ich hatte auch mal die PHP-Info Seite von Version 7 und 8 verglichen. Insgesamt 65 Unterschiede. Das meiste ist sicherlich zu ignorieren, aber wie gesagt: PHP ist nicht so zwingend meins ;-)

Grad noch mal rumprobiert: Egal, was ich in die php.ini reinschreibe...der sys_temp_path ändert sich nicht. Kann das ein Servercaching Problem sein?

Es scheint aber dennoch der richtige Wert bereits eingetragen zu sein:

Bildschirmfoto 2022-04-08 um 01.28.03.png

Gibt es denn hier Hosteurope-Kunden, die das Problem nicht (mehr) haben?

**whitedrow** · 24.04.2022, 22:54

Moin,

ist schon wein Weilchen her, aber es gibt ein Update

TLDR
Hosteurope geht nicht, Hetzner geht!

Ich habe in der Zwischenzeit viel mit Hosteurope gesprochen. Mit dem Support und dem Vertrieb und was weiß ich nicht.
Nach wie vor ist (aus welchen Gründen auch immer) nicht wirklich klar, warum es (bei meinen Projekten) nicht funktioniert.
Es wurde aber irgendwann albern, auf Supportanfragen immer die gleichen - nichts bringenden - Hinweise zu erhalten.

Ergebnis
Bei Hosteurope (Shared Hosting) habe ich eine Contao 4.13 Version unter PHP 8.0 nicht zum Laufen bringen können!

Vielleicht kommt das in der Zukunft, ich weiss es nicht, aber so kann ich weder arbeiten, noch meinen Kunden plausibel erklären, warum deren Website jetzt mehrere Monate vermutlich nicht mehr funktioniert ;-)

Lösung
Ich bin nicht dem Ratschlag des Vertriebs gefolgt, doch auf ein Managed Server zu wechseln. Das hätte eine Preiserhöhung von 2000% (kein Witz) mit sich gebracht.
Ich habe mir einen neuen Provider gesucht. Auch wieder Shared Hosting. Sogar noch ein wenig gespart. Die Welt ist wieder schön.

Allerdings habe ich jetzt diverse Kunden-Providerwechsel vor mir...

**rusty** · 20.05.2022, 10:40

Eine Lösung hat sr-tag im Contao-Manager Wiki (Eintrag 21.02.2022) beschrieben und weiter oben in diesem Thread.

Hat für mich funktioniert.

**Caro** · 11.08.2022, 15:00

Ich habe vor ein zwei Wochen eine 4.13.x Installation bei HE aufgesetzt, das hat mit der php.ini Lösung und PHP 7.4 funktioniert. Mit PHP 8.0 ging das nicht. Jetzt trudeln gerade Mails von HE ein, dass im November PHP 7.4 abgeschaltet wird. Ich habe - da diese Website noch nicht online ist - im KIS auf PHP 8.0 umgestellt und das hat tatsächlich funktioniert. Frontend, Backend und CM lassen sich aufrufen.

Vielleicht möchte jemand mal diesen Weg ausprobieren und Bescheid geben, ob es auf diesem Weg tatsächlich funktionieren kann?

Und zweite Frage: Gibt es neuere Antworten vom HE-Support, ob sich das Problem von HE-Seite aus lösen lässt?

VG
Caro