Konnte die Datei nicht auf die Festplatte kopieren.

  • Kann ich, obwohl ich mal gelesen habe, dass man das nicht mal so veröffentlichen sollte :mrgreen:

    Solange Du die nicht ständig abrufbar hast, ist das kein Problem. Du kannst aber bei schweren Bedenken eine in einem leeren Verzeichnis erstellen, dieses mit .htaccess schützen und dann jottlieb und mir Link und PW per PN senden.

    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

  • Hab es mir mal angeschaut, es ist eigentlich nichts auffälliges dabei. Ich bin mir sehr sicher, dass es ein Problem beim Hoster ist. Möglicherweise gibt es ein Problem mit dem temporären Verzeichnis (Zugriffrechte, Quota).

    Könntest Du vielleicht testweise irgendein 08/15-Uploadscript installieren und schauen, ob HTTP-Uploads überhaupt funktionieren?

    Achja, die info-Datei solltest Du jetzt seeehr schnell (schneller als sonst ;-)) löschen.

  • Achja, falls testhalber mal woanders Webspace brauchst, dann sag hier im Thread bescheid. Dann könnte ich dir schnell einen Account einrichten.

    "Eine gut gestellte Frage ist schon halb beantwortet."

  • es ist eigentlich nichts auffälliges dabei. Ich bin mir sehr sicher, dass es ein Problem beim Hoster ist. Möglicherweise gibt es ein Problem mit dem temporären Verzeichnis (Zugriffrechte, Quota).
    Könntest Du vielleicht testweise irgendein 08/15-Uploadscript installieren und schauen, ob HTTP-Uploads überhaupt funktionieren?

    Mein Hoster sagt, es würde an wp liegen.

    wenn ich wüsste, wie sehr wahrscheinlich -ja:mrgreen:.
    Möchtest du mal als Admin ins WP-Admin? würde ich dir vertrauensvoll erlauben :mrgreen:

    Zitat


    Achja, die info-Datei solltest Du jetzt seeehr schnell (schneller als sonst ;-)) löschen.

    erledigt :mrgreen:

  • wenn ich wüsste, wie sehr wahrscheinlich -ja:mrgreen:.
    Möchtest du mal als Admin ins WP-Admin? würde ich dir vertrauensvoll erlauben :mrgreen:

    Jau, hab grad was Zeit. :-) Schick mal rüber. Kannst Du auch verschlüsselt via http://www.zirona.com/kontakt machen. FTP-Zugang wäre auch nicht verkehrt, dann könnte ich kurz ein anderes Upload-Script testen.

    Es ist übrigens keine gute Idee gewesen, das phpinfo als Dump in HTML zu speichern. Auf diese Weise wurden Deine Cookies in der Datei gespeichert, und in den Cookies stand u.a. Dein WordPress-Passwort als MD5-Hash. Den hätte ich mit etwas Glück in zwei Sekunden, mit Pech in knapp zwei Stunden geknackt.

  • aha, danke für den hinweis:mrgreen:...

    ich schick dir meine ftp-zugangsdaten, auch meine daten für wordpress über dein formular. bin dann mal 2 stunden außer Haus zum Friseur. Melde mich dann später :-)

  • So, das Problem habe ich immer noch, ABER:

    wenn ich per FTP ein Bild hochlade und es im WP-Editor quasi per Hand verlinke, dann wird es auch nach dem Speichern des Artikels, angezeigt.

    Mit Wordpress kann ich kein Bild hochladen, ich frage mich dennoch, was da kaputt ist und hoffe, das mein Fehler mit dem (kommenden) update auf WP 2.1 weg ist.

  • Ich hatte das selbe Problem mit Wordpress. Die WP-Einstellungen waren korrekt und die Ordner hatten die korrekten Zugriffsrechte. Dazu funktionierte der Upload nur im Wordpress nicht und deshalb konnte ein Problem mit dem Server ausgeschlossen werden.

    Nach einigen Suchen bin ich dann auf das Problem gestossen: open_basedir
    Ist die Funktion in PHP aktiviert, kann ein Skript nur auf Dateien zugreifen, die im selber Verzeichnis oder darunter liegen. Nicht aber auf Datien, die in höheren Verzeichnissen sind.

    Das Problem liegt also am Wordpress: Das Upload-Skript liegt im wp-admin Ordner. Relativ dazu liegt das Standard-Uploadverzeichnis also im Pfad "../wp-contents/uploads". Da das aber in einem höheren Verzeichnis ist, wird der Zugriff von open_basedir verhindert.

    Es gibt drei Möglichkeiten, das Problem zu lösen:
    - Änderung von Wordpress, so dass über ein Skript im Grundverzeichnis der Upload verarbeitet wird. Damit wird der Pfad zu "wp-contents/uploads" und das Skript kann auch mit open_basedir darauf zugreifen. Das müsste aber ein Wordpress-Entwickler machen.
    - open_basedir deaktivieren oder das Grundverzeichnis zu den open_basedir Pfaden hinzufrügen. Das geht nur über die Server-Konfiguration und dürfte nicht bei allen Hostern möglich sein.
    - Das Uplaod-Verzeichnis in den Ordner wp-admin verschieben. Keine schöne Lösung, damit sollten Uploads aber wieder funktionieren.

  • Hallo,

    ich denke nicht, dass es an Wordpress selbst liegt. Ich habe seit gestern das gleiche Problem nach einer Umstellung eines Servers von PHP4 auf PHP5. Ich bin noch am rätseln woran das genau an PHP5 liegt.

    Ich vermute dass der Hoster seinen Server geupdatet hat, dass ist die einzigste Erklärung die mir einfällt, da ich selbst ein Hoster bin.

    *EDIT*
    Also das Problem scheint definitiv an der PHP5 Etch Version zu liegen. Ich habe soeben auf PHP4 wieder umgestellt und schon geht wieder der Blogger. Nun, also entweder hat PHP5 in der aktuellen Version ein Bug oder Wordpress kommt nicht mit der Version klar. Eines von beiden wird es wohl sein :-)

    Einmal editiert, zuletzt von marcolein (27. April 2007 um 17:01)

  • Hallo,

    Ist das noch aktuell? Ich hatte gerade das gleiche Problem nach der Umstellung von PHP4 auf PHP5 (im Zuge der Umstellung von Debian-Sarge auf Etch, könnte also noch mehr Umstellerei daran schuld sein).

    In der php.ini gibt es einen Eintrag "open_basedir" der steht bei mir auf "/pfad/zum/blog". Das war auch schon bei PHP4 so.

    Seit der Umstellung scheint auch noch "upload_tmp_dir" wichtig zu sein, das hatte vorher keinen Eintrag in der ini. Ich hab mir also ein Verzeichnis "/pfad/zum/blog/temp/" angelegt und mit den Einstellungen

    Code
    open_basedir    /pfad/zum/blog
    upload_tmp_dir  /pfad/zum/blog/temp

    funktioniert das Bilderhochladen wieder.

    Grüße, Max

  • Hallo Max,

    das Problem besteht nach wievor. Das hat nicht wirklich etwas mit Debian Etch zu tun, eher mit der PHP5 Version (Version 5.2.0-8 Etch) unter Debian Etch. Mit PHP4 gibt es keinerlei Probleme, auch unter Etch nicht.

    Ich habe auch bei Kollegen nachgefragt, die das Problem auf eigenen Servern bestätigen konnten.

    Sicher mag das mit der Eintragung in der php.ini zu funktionieren, ist jedoch keine Dauerlösung wenn man Hoster ist und viele viele Kunden hat. Und extra httpd Special Einträge anlegen macht auch kein Sinn, da die Pfade des Wordpress von Kunden immer unterschiedlich sein können. :neutral:

  • Ich hab nicht ausprobiert, was passiert, wenn upload_tmp_dir nicht innerhalb von open_basedir liegt. Vielleicht geht das auch, dann müsste der Massenhoster die Variable nur einmal setzen (wobei er sich halt Gedanken mache muss über den Umstand, dass dann auch alle das gleiche Verzeichnis nutzen. Oder er muss es so setzen dass es im Kontext der einzelnen User doch wieder ein userspezifisches Verzeichnis ist, also irgendwas in dessen Home-Verzeichnis).

    Nachträglich pro User bei schon vorhandenen Kunden ändern ist allerdings echt ein Problem....

    Wenn es in der Kombination Etch/PHP4 auch geht, ist es ein PHP5-Problem. Ich hab Etch/PHP4 in dieser Hinsicht nicht ausprobiert, ich hab zwar nach dem Upgrade auf Etch schon brav getestet, ob mein Blog geht, bin aber nicht auf die Idee gekommen, auch speziell das Bilderhochladen nochmal zu testen.:-|

  • Ohje. Jetzt hat mich genau dieses Problem bzw. diese Fehlermeldung erwischt -- mit WP 2.5.1 allerdings!
    Habe das hier dokumentiert -- vielleicht hat ja jemand einen Tipp? Das nervt leider sehr und macht WP quasi unbrauchbar ... :-(

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!