[erledigt] Die angegebene Datei temporary://file9XaXJJ konnte nicht kopiert werden ...
Eingetragen von Anna Bolika (26)am 14.02.2011 - 20:09 Uhr in
Ich bin seit einer Stunde beim Fehlersuchen und verzweifle langsam. Es gibt zu dieser Überschrift bereits eine Frage hier, die Antwort bringt bei mir leider keinen Erfolg.
Was bisher geschah:
Ich betreibe mehrere Auftritte mit Drupal 7 als Multi-Site-Installation. Besser gesagt, ich möchte es. Einer läuft bereits fehlerfrei mit dem gleichen Programmcode. Ein paar andere zeigen zumindest die Startseite fehlerfrei.
Das letzte, was ich tat, war das Modul "Contact" einzubinden (dieses Modul ist beim funktionierenden Nachbar-Auftritt nicht aktiviert). Das Kontaktformular sah gut aus, nur diese Funktion "mir eine Kopie per E-Mail senden" machte mir Kopfschmerzen wegen Spam. Also habe ich Mollom aktivieren wollen (das auf dem laufenden Nachbarprojekt auch aktiviert ist.).
Seitdem sieht der Kopf jeder Seite so aus:
Die angegebene Datei temporary://fileZyHlfC konnte nicht kopiert werden, da das Zielverzeichnis nicht richtig konfiguriert ist. Dies könnte durch Probleme bei der Berechtigung im Dateisystem verursacht werden. Weitere Informationen finden Sie im System Log.
Die angegebene Datei temporary://filebwgyMG konnte nicht kopiert werden, da das Zielverzeichnis nicht richtig konfiguriert ist. Dies könnte durch Probleme bei der Berechtigung im Dateisystem verursacht werden. Weitere Informationen finden Sie im System Log.
Ich habe nicht eine, sondern ALLE files-Verzeichnisse geprüft, die in Frage kommen könnten. Ich habe sogar für den "all" und den "default"-Ordner ein files-Verzeichnis angelegt, obwohl dort eigentlich keine drin sein müssten Alle haben die Rechte 777.
Das in der Konfig eingestellte tmp-Verzeichnis liegt irgendwo außerhalb meines Einflussbereichs (Hosteurope-Webpack). Also habe ich ein neues angelegt und mit 777 ausgestattet. Kein Erfolg.
Ich habe es nun wieder zurückgeändert auf das tmp-Verzeichnis, mit dem das Nachbarprojekt fehlerfrei läuft.
Immer wieder wird auch auf das Syslog verwiesen. Ist das der Menüpunkt "Berichte"? Dort steht bei Dateisystem: Beschreibbar (öffentliche Download-Methode)
Ich bin ratlos. Hat jemand eine Idee, was ich noch ausprobieren könnte?
-----
Falls mal jemand dieses Problem hat. Bei mir lag es daran, dass unter dem /files-Verzeichnis weitere Verzeichnisse waren, die keine 777-Rechte besaßen. Nachdem ich das behoben habe, läuft nun alles.
- Anmelden oder Registrieren um Kommentare zu schreiben
Danke
am 04.04.2011 - 13:59 Uhr
das hat mir eben sehr bei der Fehlersuche geholfen :-)
Mir hat die Lösung auch sehr
am 27.05.2011 - 21:41 Uhr
Mir hat die Lösung auch sehr geholfen. Vielen Dank für den Hinweis.
Mir auch, Danke!
am 29.06.2011 - 10:33 Uhr
Mir auch, Danke!
Weiterer Lösungsvorschlag
am 11.05.2012 - 17:36 Uhr
Sry, dass ich diesen Thread nochmal aufleben lasse,
aber ich hatte heute das gleiche Problem und vlt hilft es jemandem.
Bei mir half das Löschen des Inhalts des von mir angelegten TMP Verzeichnisses in /var/www/webxx/files/DrupalTMPVerzeichnis
Dabei habe ich festgestellt, dass der Ordner "styles" sich nicht löschen liess. Ich habe diesen Ordner dann per root/SSH gelöscht.
Nach dem Löschen ging das Updaten der Module wieder, allerdings wurde ein weiteres Symptom, nämlich, dass das Admin Menü nur alle Menüs hatte, wenn ich den Cache löschte nicht beseitigt. Das habe ich beseitigt, in dem ich in der Administrationsmenü-Konfiguration den Haken bei:
Cache menu in client-side browser entfernt habe (wobei ich mir absolut nicht vorstellen kann, was das damit zu tun haben soll (Stichwort Client-side), muss also nicht unbedingt ein sideeffekt gewesen sein, sondern ein eigenes Problem).
Leider (!) ist danach beim Löschen des Cache ein Whitescreen aufgetreten. Nach Stundenlanger Suche, ein/ausschalten der errormessages etc, musste ich das genutzte Memory-Limit auf 128 hochsetzen (was ein Act ist, auf einem für einen Provider konfigurierten Server).
Nun... die Seite ging wieder und ich versuche nun mit 64MB weiter zu verfahren. Höhere Limits kosten Geld und ich fände es schade, wenn Drupal nicht mit 64 auskommt, denn sogar das ist mehr, als viele Provider erlauben.
Ich hatte also Glück, dass ich root Zugriff hatte, ansonsten hätte nur noch ein Telefonat bei der Providerhotline oder das Einspielen eines Backups geholfen.
LG Lars
P.S.: Es kann auch sein, dass der Provider ein Systemupdate gemacht ha (so schon passiert) und sich die Berechtigungen der von Drupal angelegten Dateien und Ordner ändert (von wwwdata zu webXX z Bsp.), dann hilft nur eine Änderung der Berechtigungen oder solange das nicht möglich ist, der Aufbau eines neuen Verzeichnisses für öffentliche Dateien, in dem man die Alten reinkopiert.
ich war schon kurz vorm
am 17.06.2013 - 07:07 Uhr
ich war schon kurz vorm verzweifeln. danke für deine Beitrag, ich stand vor dem gleichen Problem und jetzt läuft alles ohne Probleme.
vielen lieben Dank !!!
Jahre später: Der Hinweis auf die Rechte unter /files ...
am 06.09.2014 - 21:15 Uhr
... war immer noch sehr hilfreich. Vielen Dank!!!
Anne