Update failed: File Transfer failed, reason: Unable to remove to directory

Das Rechteproblem liegt beim Temporären Filesystem. Ist bei Deiner Installation der Safe_Mode auf ON? Der sollte nämlich auf OFF stehen.

Beste Grüße
Werner

Vielen Dank für deinen Hinweis. Habe zum Thema Safe_Mode mal ein bisschen rumgesucht. Den kann man ja wohl über die .htaccess-Datei abstellen, siehe http://www.daniweb.com/web-development/php/threads/18424

Also habe ich in meine .htaccess-Datei im Drupal-Verzeichnis eingetragen:

php_value safe_mode "0"

Das ändert am Ergebnis nichts. Auch wenn ich dasselbe in die .htaccess-Datei in mein temporäres Verzeichnis schreibe.

Hast du noch einen Tipp für mich, wie ich das mit dem Safe_Mode bewerkstellige?

Falls das wichtig ist: Ich habe ein WebPack L 3.0 bei Host Europe.

Was hast Du denn unter Konfiguration > Media > Dateisystem für das temporäre Filesystem eingetragen? Vermutlich liegt der Fehler da.

Beste Grüße
Werner

Ich habe da eingetragen: /is/htdocs/wp1148426_UTITQDF1GG/drupal7-temp

Ich kann diesen Ordner dann auch mit FTP sehen und sehe auch, dass die Module nach dorthin heruntergeladen und auch entpackt werden.

Ursprünglich war dort eingetragen: /is/htdocs/user_tmp/wp1148426_UTITQDF1GG/

Das ist der Pfad, der bei Host Europe als Tmp-Pfad angegeben ist. Das hatte aber auch nicht funktioniert. Und dort kann ich nicht per FTP reinschauen.

Das kann so nicht funktionieren. Trage einfach sites/default/files/tmp ein. Danach solltest Du vom Server eine Rückmeldung bekommen, daß dieses Verzeichnis angelegt wurde. Du kannst keine Verzeichnisse benutzen, die außerhalb des vom Webserver ansprechbaren Pfades liegen.

Beste Grüße
Werner

Danke für den Hinweis. Habe das tmp-Verzeichnis wie von dir vorgeschlagen eingestellt. Verzeichnis wird auch angelegt und die Modul-Dateien tauchen dort auf. Die Fehlermeldung bleibt aber dieselbe. :-(

Noch eine Idee?

Hast Du das files Verzeichnis (sites/default/files) und alle seine Unterordner auf 777 bei den Rechten stehen?

Beste Grüße
Werner

Ja, habe ich. Hab's gerade noch einmal überprüft.

Das tmp-Verzeichnis scheint mir gar nicht das Problem zu sein. Sieht eher so aus, als ob die Modul-Verzeichnisse nicht gelöscht werden können: "Unable to remove to directory /www/drupal7/sites/all/modules/..."

???

Try changing your entire 'all' folder to 777

As you said, it seems to need permission to first remove the existing module, rather than simply to overwrite it.

Du hast Deine Drupal-Module mit FTP auf den Sever geschoben und versuchst jetzt über den Webserver-Prozess den Update. Da der Webserver aber nicht die Rechte auf den Verzeichnissen hat, geht das nicht. Du solltest den Owner der entsprechenden Verzeichnisse auf den Webserver-Prozess ändern. Generell die Rechte im all-Verzeichnis auf 777 zu ändern ist keine so gute Idee.

Beste Grüße
Werner

Hatte zunächst gedacht, das Problem hätte sich "von alleine" gelöst nach dem Update auf Drupal 7.12. Besteht aber immer noch (siehe Anlage). Werde mit den Rechten nochmal experimentieren und hier weiter berichten.

Hi Ralf,

Du bist mit Deinem Problem nicht zufällig auf einem Mac in einer lokalen Installation unterwegs? Da hatte ich das Problem nämlich auch, aber zwischenzeitlich eine Lösung gefunden. Eine etwas längere Antwort findet sich hier [1]. Die kurze Antwort lautet, dass die Permissions von Owner und Group beim Temp-Ordner und beim Modules-Ordner identisch sein müssen, damit zwischen ihnen geschrieben werden kann. Zugriffsrechte sind bei beiden standardmäßig 755.

[1]: http://forum.mamp.info/viewtopic.php?f=2&t=14830&p=29896&hilit=permissio...

Nein, bei mir ist das keine lokale Installation, sondern eine bei Host Europe. Ich habe jetzt als Temp-Verzeichnis mal eingestellt:

* /drupal7-temp, Besitzer: ftp_xyz, Gruppe: wp_xyz, Rechte: 775

Konkret geht es um das Update des Omega-Themes. Die Ordner /www/drupal7/sites/all/themes, /www/drupal7/sites/all/themes/omeage und alle darunter liegenden Ordner bzw. Dateien haben folgende Einstellungen, wobei ich die Rechte schon händisch gesetzt habe.

* Besitzer: ftp_xyz, Gruppe: wp_xyz, Rechte: 775

Wenn ich nun das Update auslöse, finde ich im (vorher leeren) Temp-Ordner zwei Verzeichnisse. Zum einen:

* update-cache-c65a30cb, Besitzer: wp_xyz, Gruppe: wp_xyz, Rechte: 775

Darin enthalten die Datei

* omega-7.x-3.1.tar.gz, Besitzer: wp_xyz, Gruppe: wp_xyz, Rechte: 664

Zum anderen:

* update-extraction-c65a30cb, Besitzer: wp_xyz, Gruppe: wp_xyz, Rechte: 775

Darin enthalten der Ordner omega mit denselben Besitzer-, Gruppen- und Rechte Einstellungen, genauso wie die darin liegenden Ordner. Die darin liegenden Dateien haben das Recht 640.

Was ich nicht verstehe: Drupal läuft offensichtlich als Benutzer wp_xyz (wobei ich hier _xyz als Platzhalter für eine 7-stellige Zahl verwende). Alle in Frage kommenden Ordner gehören zu der passenden Gruppe und diese hat alle Rechte, alle Dateien gehören entweder zu der Gruppe oder zu dem Benutzer, der dann auch wiederrum alle Rechte hat.

Benutzt jemand von Euch Hoste Europe mit Drupal 7 und hat dieselben Probleme? Oder hat sonst noch jemand eine Idee?

Wäre eigentlich eine Frage, auf die der Host Europe Support eine direkte Antwort haben sollte (insbesondere, weil es ja teilweise wohl schon im Hostingpaket von denen drin ist). Da Du da vermutlich auf einem Shared Host bist, sollte "eigentlich" der Temp-Ordner an einer anderen Stelle sein (nämlich gängig oberhalb des html-Ordners). So, weit, wie Du es beschreibst, bin ich auch auf meiner lokalen Installation mit falschen Rechten gekommen (d.h. Download klappt, Download wird entpackt und das schreiben des Download-Ordners in den Modules-Ordner versagt). Ich würde an Deiner Stelle noch einmal schauen, wie das mit dem vom Provider vorgesehenen temp-Ordner ist und wie es sich da mit den Rechten und den Besitzern verhält. Sofern es tröstet: Ich werde bis zum Ende des Monats bei einem anderen Provider eine Drupal-Installation auf einem Shared Host aufsetzen und gerne berichten, sofern es da zu Problemen kommen sollte.

Hallo Ralf,

bei HostEurope hast Du automatisch ein tmp Verzeichnis, das ausserhalb des Root liegt. Dieses wird benutzt, wenn Du keinen Pfad in der Drupal Installation angibst. Den Pfad findest Du im KIS unter https://kis.hosteurope.de/administration/webhosting/admin.php?wp_id=HIER DEINE PAKETNUMMER ANHÄNGEN

Alternativ kannst Du auch einen Ordner auf der Rootebene von Drupal erstellen und auf diesen verlinken. Ich benutze diese Variante, weil ich dann zwischendurch immer mal den tmp Ordner händisch leeren kann.

Was die Rechte angeht, so habe ich mal meine per Screenshot festgehalten....

Richtig, bei mir lag das Temp-Verzeichnis vorher auch außerhalb von root, wo ich nicht reinschauen konnte. Deshalb hatte ich das nach root verlegt (und unter /admin/config/media/file-system mit dem Pfad aus dem KIS eingetragen eingetragen, also /is/htdocs/wp_xyz_/drupal7-temp).

Habe hier noch was zur Konfiguration des WebPacks betr. Benutzer gefunden: http://faq.hosteurope.de/index.php?cpid=16595

Hallo Ralf,

das ist aber doch so nicht richtig.... bei mir heißt das Verzeichnis tmp und liegt auf der gleichen Ebene wie includes, themes, sites, profiles, etc. ; daher lautet der korrekte Eintrag einfach tmp und gut.

Hallo Kirsten,

und funktioniert's bei dir dann eigentlich oder nicht?

Ralf

... auf allen Websites, die ich erstellt habe (meine und für Freunde) - alle bei HostEurope

siehe meine Signatur...

Hm, das ist interessant. Trotzdem muss das einen anderen Grund haben. Ich habe mal provisorisch das temporäre Verzeichnis auf "tmp" gesetzt - genau wie bei dir - das hat am Ergebnis aber nichts geändert. :-(

Daß es eher das Zielverzeichnis ist.
Dessen Rechte auf 777, dann sollte es funktionieren.

Wurde das Problem inzwischen gelöst? Habe das selbe Problem beim Update Manager. Benutze auch Hosteurope.

Nein, leider noch nicht. :-(

Ich hatte das gleiche Problem. Hosting bei Hosteurope und kein Update von Modulen möglich.

Funktioniert hat das Updaten von Modulen, nachdem ich in der Dateiverwaltung des Kis von Hosteurope, den "Benutzer" der einzelnen Modulordner in sites/all/modules/xxxxxx " von ftpxxxxxx auf wpxxxxxx gesetzt habe. So, wie es in deinem Hosteurope Link beschrieben und dem Bild von Kirsten zu sehen ist.
Das tmp Verzeichniss habe ich nicht angefasst.

Das Problem hatte ich so das erste mal. Andere Drupal7 installationen updaten ohne Probleme trotz "Benutzer: ftpxxxxx".

Die hier betroffene Installation hatte ich aus einem anderen Verzeichniss heruntergeladen und in ein neues Verzeichniss auf dem Server kopiert, vielleicht deshalb die Probleme mit den Dateirechten.

Grüße
Andreas

Ich frage nochmal nach, denn ich stehe gerade vor dem gleichen Problem. Bin gerade dabei, meine diversen D6-Installationen auf D7 umzustellen, was sowieso schon aufwändig genug ist. :-/

Ich habe jetzt, glaube ich, so ziemlich alle hier vorgeschlagenen Lösungswege ausprobiert, ohne Ergebnis.

Bei einer weiteren D7-Installation bei All-inkl.com hatte ich kurzzeitig das gleiche Phänomen. Dort konnte ich es lösen, weiß aber blöderweise nicht mehr wie.

Hab nach viel lesen und probieren nun endlich die Lösung für das Problem gefunden (Hosteurope):

und zwar reicht es nicht einfach aus nur für den Ordner Modules den Besitzer auf WP zu ändern sondern das muss auf den ganzen Ordner Sites (+ unterordner) erfolgen.

Zudem habe ich einen neuen FTP WP-Benutzer bei Hosteurope angelegt und diesen bei der Update Funktion angegeben. Damit hat es funktioniert!

Hoffe das hilft jemanden, extra für den Post hier angemeldet!

Cheers!

Den ganzen Ordner sites auf WP zu ändern hat ausgereicht. Vielen Dank für den Tipp! Mal sehen, ob es sonst irgendwelche Auswirkungen hat.

das es nicht nur bei mir geklappt hat!

falls es doch noch andere Auswirkungen haben sollte, lass es mich wissen!

Jetzt geht's tatsächlich auch bei mir. Und zwar muss man wirklich den "sites"-Ordner (im KIS) auf "Benutzer WPxxxx" stellen. Dann passiert folgendes: Der _Besitzer_ des "sites"-Ordner wird - was man per FTP-Client überprüfen kann - auf Benutzernamen "ftpxxxx-xxxxx" eingestellt. Also genau auf den Namen, den man im KIS unter "Allgemeins > FTP-Zugänge" als Benutzernamen angelegt hat. Wobei ich dort in der Spalte "Benutzer" auf "WPxxxx" gestellt habe.

Alles irgendwie ganz schön verwirrend. So richtig steige ich eigentlich immer noch nicht durch - auch wenn's jetzt immerhin schonmal im Ergebnis funktioniert. :-)

Ich bin der Sache nochmal nachgegangen. So sieht jetzt meine Lösung jetzt aus:

1. Ich habe mir im KIS unter "Allgemeins > FTP-Zugänge" zwei FTP-User angelegt:
   1. Benutzername ftpxxxx-ftp, Benutzer ftpxxxx
   2. Benutzername ftpxxxx-wp, Benutzer wpxxxx

   Lade ich damit per FTP-Client Dateien hoch, erscheinen die Rechte wie folgt:

   1. ftpxxxx-ftp: Besitzer fptxxxx, Gruppe wpxxxx
   2. ftpxxxx-wp: Besitzer fptxxxx-wp, Gruppe wpxxxx

2. Das gesamte Drupal-Verzeichnis habe ich im KIS unter "Allgemeins > Dateiverwaltung" rekursiv auf 750, Besitzer ftpxxxx, Gruppe wpxxxx gestellt.
3. Damit das mit den Updates funktioniert, muss man wie oben schon beschrieben das sites-Verzeichnis (rekursiv) auf Besitzer wpxxxx stellen. Die Rechte habe ich dann auf 770 gestellt, damit ich auch per FTP noch schreiben kann.
4. Die settings.php habe ich auf Besitzer fptxxxx, Gruppe wpxxxx und 750 gelassen.
5. Beim Update werde ich nach den FTP-Zugangsdaten gefragt. Da habe ich den Benutzername ftpxxxx-wp angegeben.

So klappt es jedenfalls. Wobei mir eigentlich immer noch nicht klar ist, warum man das so machen muss und warum das nicht genügt, wenn der Benutzer ftpxxxx-wp über die Gruppe Schreibrechte im sites-Verzeichnis hat.

Die wahre Lösung des Problems ist hier zu finden http://drupal.org/node/1900580#comment-7248938 ,
und eine genaue Beschreibung der Ursache hier: http://drupal.org/node/1900580#comment-7075312 .

Ab Drupal 7.22 sollte wieder alles in Butter sein: Der Patch im comment #10 http://drupal.org/node/1915088#comment-7139886 ist allem Anschein nach bereits commited (siehe comment #30 http://drupal.org/node/1915088#comment-7238292 ).

ich werde mal die oben skizzierte Lösung versuchen.