Die hochgeladene Datei konnte nicht nach wp-content/uploads verschoben werden: 8 Lösungen

Du lädst ein Bild, ein PDF oder eine andere Datei in die WordPress Mediathek hoch und der Vorgang endet mit genau dieser Meldung. Das bedeutet: WordPress hat die temporär gespeicherte Datei angenommen, konnte sie aber nicht in den endgültigen Upload-Ordner verschieben.

Teste zuerst eine zweite, kleine JPG- oder PNG-Datei. Prüfe danach Site Health, freien Speicher und Inodes, den konfigurierten Upload-Pfad, Rechte und Eigentümer sowie das PHP-Temp-Verzeichnis. Der Zahlenpfad ist nicht fest: Je nach Monat kann dort etwa wp-content/uploads/2026/01, 2026/02, 2026/04 oder 2025/12 stehen. In dieser Anleitung verwenden wir deshalb /YYYY/MM.

Die Meldung stammt aus der WordPress-Upload-Verarbeitung. WordPress prüft zunächst Upload-Status, Dateigröße und Dateityp. Dann bestimmt wp_upload_dir() das Ziel und versucht, die temporäre PHP-Datei dorthin zu verschieben. Schlägt dieser letzte Schritt fehl, entsteht die Meldung „The uploaded file could not be moved to …“. Das lässt sich im WordPress-Core zur Upload-Verarbeitung nachvollziehen.

Ein WordPress upload file permission error ist eine häufige Ursache, aber längst nicht die einzige. Ein volles Hosting-Konto, verbrauchte Inodes, eine falsche Eigentümerschaft oder ein unzugängliches temporäres Verzeichnis sehen für WordPress am Ende ähnlich aus: Die Zieldatei kann nicht geschrieben werden.

1. Andere kleine Datei testen: Lade eine bekannte JPG- oder PNG-Datei mit wenigen Kilobyte hoch. Funktioniert sie, prüfe Dateityp, Dateiname und Größenlimit der ursprünglichen Datei getrennt.
2. WordPress Site Health prüfen: Öffne Werkzeuge > Site Health > Info > Dateisystemrechte. Der Eintrag „The uploads directory“ sollte „Writable“ anzeigen. Dieser Abschnitt ist in aktuellen WordPress-Versionen vorhanden.
3. Speicherplatz und Inodes prüfen: Ein freier Gigabyte-Wert hilft nicht, wenn das Inode-Limit bereits erreicht ist.
4. Upload-Pfad kontrollieren: Ermittle, ob WordPress wirklich wp-content/uploads/YYYY/MM verwendet oder eine alte Sonderkonfiguration aktiv ist.
5. Rechte und Eigentümer vergleichen: Prüfe den Hauptordner und den aktuellen Jahres-/Monatsordner.
6. PHP-Temp-Verzeichnis prüfen: upload_tmp_dir muss für den PHP-Prozess erreichbar und beschreibbar sein.
7. Hosting-Support kontaktieren: Gib den exakten Pfad und einen konkreten Zeitpunkt an, damit der Hoster das passende PHP- und Webserver-Log prüfen kann.

Beginne hier, weil sich diese Ursache ohne Eingriff in Dateien oder Konfiguration ausschließen lässt. Ein Hosting-Konto kann sein disk quota erreicht haben, obwohl die hochgeladene Datei klein ist. Beim Upload entstehen neben der Originaldatei oft Vorschaubilder. Außerdem benötigen Caches, Backups, Logs und Updates Platz.

Ein Inode steht vereinfacht für einen Dateisystemeintrag. Zeigt das Hosting noch freien Speicher, aber keine freien Inodes, kann PHP keine neue Datei anlegen. Lösche nichts blind. Prüfe zuerst, ob alte Backups, Cache-Dateien oder Staging-Kopien den Verbrauch erklären, und nutze die dafür vorgesehene Bereinigung deines Hosters oder Plugins.

Bei einer WordPress Multisite kommt ein weiteres Limit hinzu: Das Upload-Kontingent der einzelnen Website kann ausgeschöpft sein, obwohl der Server noch Platz hat. Prüfe als Netzwerk-Administrator die Speichergrenze der betroffenen Site.

Mit SSH sind diese rein lesenden Befehle hilfreich:

df -h
df -i

df -h zeigt belegten Speicher, df -i die Inode-Auslastung. Auf Managed Hosting kann das Konto eine zusätzliche Quote haben, die diese Serverwerte nicht vollständig abbilden. Dann ist die Anzeige des Hosters maßgeblich.

Der Standardpfad lautet wp-content/uploads. Ist die Option zur Organisation nach Jahr und Monat aktiv, hängt WordPress den Datumsordner an. Die Struktur sieht dann so aus:

wp-content/
└── uploads/
    └── YYYY/
        └── MM/
            └── deine-datei.jpg

Kontrolliere per SFTP, FTP oder Hosting-Dateimanager, ob uploads, der Jahresordner und der aktuelle Monatsordner existieren. Ein fehlender Monatsordner ist nicht automatisch ein Fehler: WordPress versucht, ihn selbst anzulegen. Kann es das nicht, ist meist der übergeordnete Ordner nicht beschreibbar oder falsch zugeordnet.

WordPress berücksichtigt intern außerdem die ältere Option upload_path. Die Konstante UPLOADS in wp-config.php kann diesen Pfad überschreiben. Die offizielle Dokumentation zu wp_upload_dir() beschreibt diese Reihenfolge. Suche nach einer Sonderkonfiguration nur, wenn der Fehler einen unerwarteten Pfad nennt oder die Website migriert wurde. Ändere den Pfad nicht grundlos.

Der Datumsordner selbst ist kein Problem. Wenn du Jahre und Monate bewusst aus bestehenden Medien-URLs entfernen möchtest, ist das eine separate Anleitung zum Verschieben von WordPress-Uploads aus Datumsordnern. Für den aktuellen Fehler muss zuerst die Schreibbarkeit wiederhergestellt werden.

Öffne in deinem SFTP-Client oder Dateimanager die Eigenschaften des betroffenen Verzeichnisses. 755 für Verzeichnisse und 644 für Dateien sind auf vielen Linux-Hostings sinnvolle Ausgangswerte. Sie sind keine universelle Vorgabe. Manche Hosting-Setups verwenden Gruppenrechte, ACLs oder eine andere PHP-Betriebsart.

Prüfe die Rechte vom Pfad von außen nach innen: wp-content, uploads, YYYY und MM. Der PHP-Prozess benötigt Schreibzugriff auf das Zielverzeichnis und Zugriff auf die übergeordneten Ordner. Die offizielle WordPress-Anleitung zu File Permissions erklärt Besitzer-, Gruppen- und öffentliche Rechte.

Wenn du SSH sicher beherrschst, zeigt dieser Befehl die aktuellen Werte, ohne sie zu ändern:

ls -ld wp-content wp-content/uploads wp-content/uploads/YYYY wp-content/uploads/YYYY/MM

Ändere Rechte nur für den nachweislich betroffenen Pfad und entsprechend den Vorgaben deines Hosters. Ein rekursives chmod über die gesamte WordPress-Installation ist für diese Fehlersuche unnötig.

Permissions bestimmen, was Eigentümer, Gruppe und andere Benutzer dürfen. Ownership bestimmt, welcher Benutzer und welche Gruppe überhaupt Eigentümer sind. Darum kann chmod 755 korrekt aussehen und der Upload trotzdem scheitern.

Dieses Muster tritt häufig nach einer manuellen Migration, einem Restore als root, einem Deployment per SSH oder dem Kopieren von Dateien zwischen Hosting-Accounts auf. Der Ordner gehört dann beispielsweise dem SSH-Benutzer, während PHP unter einem anderen Account oder in einer anderen Gruppe läuft.

Vergleiche Eigentümer und Gruppe von wp-content/uploads mit einem Ordner, in den WordPress nachweislich schreiben kann. Führe keinen kopierten chownBefehl aus, solange du den korrekten Hosting-Benutzer nicht kennst. Auf Shared Hosting kann meist nur der Support die Zuordnung zuverlässig korrigieren. Sende ihm den Zielpfad und bitte konkret darum, owner, group und ACLs für den PHP/Webserver-Prozess zu prüfen.

Ein Browser-Upload landet zunächst in einem temporären Verzeichnis des Servers. Erst danach verschiebt WordPress die Datei in die Mediathek. Die PHP-Einstellung upload_tmp_dir kann einen eigenen Ordner vorgeben. Fehlt dieser Ordner, ist er voll oder kann PHP ihn nicht lesen und schreiben, entsteht ein WordPress temporary folder upload error.

Auch open_basedir kann den Zugriff begrenzen. Der temporäre Ordner und das endgültige Upload-Verzeichnis müssen innerhalb der für die Website erlaubten Pfade liegen. Auf Managed oder Shared Hosting solltest du diese Werte im PHP-Info-Bereich des Hosters prüfen oder den Support fragen. Bearbeite php.ini oder .user.ini nur, wenn der Hoster diese Methode dokumentiert. Eine zufällige Datei aus einem fremden Tutorial kann PHP-Einstellungen für die ganze Website beschädigen.

Mit SSH liefern diese Befehle Hinweise, wobei die PHP-Konfiguration der Kommandozeile von der Web-PHP-Version abweichen kann:

php --ini
php -i | grep -E 'upload_tmp_dir|open_basedir'

Wenn Site Health den Upload-Ordner als beschreibbar meldet, Speicher und Inodes frei sind und trotzdem jede kleine Datei scheitert, lohnt sich diese Prüfung besonders.

Diese Lösung ist nur sinnvoll, wenn der aktuelle YYYY/MMOrdner fehlt, leer ist oder nachweislich mit falscher Eigentümerschaft angelegt wurde. Lösche niemals einen Monatsordner mit bestehenden Mediendateien.

1. Erstelle ein vollständiges Backup von wp-content/uploads und der Datenbank.
2. Prüfe, ob im betroffenen Monatsordner Dateien liegen. Sind Dateien vorhanden, repariere Rechte und Eigentümer, statt den Ordner neu zu erstellen.
3. Lege nur einen fehlenden Ordner über SFTP oder den Dateimanager an, zum Beispiel zuerst YYYY und darin MM.
4. Übernimm Rechte, Eigentümer und Gruppe von einem funktionierenden benachbarten Monatsordner desselben Hosting-Accounts.
5. Lade eine kleine Testdatei hoch. Prüfe anschließend, ob sie in der Mediathek erscheint und über ihre URL erreichbar ist.

Ist ein leerer Ordner defekt, verschiebe ihn zunächst mit Hilfe des Hosters an einen Backup-Namen, statt ihn sofort zu überschreiben. So bleibt die Änderung rückgängig machbar.

Security-Plugins, eine Web Application Firewall, ModSecurity oder eine Hosting-Regel können Uploads blockieren. Das ist wahrscheinlicher, wenn nur bestimmte Dateiendungen, Dateinamen oder Requests betroffen sind. Eine blockierte Dateiendung erzeugt in WordPress gewöhnlich eine andere Meldung als der fehlgeschlagene Move. Behandle sie deshalb als separate Fehlerklasse.

Teste eine kleine Standard-JPG-Datei. Funktioniert sie, vergleiche Dateiendung, MIME-Type, Dateiname und Größe mit der problematischen Datei. Prüfe die Ereignis- oder Blockierungsprotokolle des vorhandenen Security-Tools. Deaktiviere nicht wahllos alle Plugins. Falls ein kurzzeitiger Test nötig ist, erstelle vorher ein Backup, nutze ein Wartungsfenster und deaktiviere nur die konkrete Sicherheitskomponente.

Bei wiederholbaren Fehlern notierst du den sekundengenauen Zeitpunkt. Der Hoster kann damit WAF-, ModSecurity-, PHP- und Webserver-Logs gezielt abgleichen.

Eine allgemeine Nachricht wie „Uploads gehen nicht“ führt oft zu Rückfragen. Kopiere stattdessen diese Checkliste und ersetze die Platzhalter:

Hänge den Site-Health-Ausschnitt an, aber entferne öffentliche IP-Adressen, Serverpfade und andere Angaben, die der Support nicht benötigt. Bei einem seriösen Hoster reichen diese Daten meist, um zwischen Quote, Ownership und PHP-Konfiguration zu unterscheiden.

• Keine dauerhaften 777-Rechte setzen. Sie machen wp-content/uploads unnötig weit beschreibbar und verdecken häufig einen Ownership-Fehler.
• Nicht ganz wp-content freigeben. Für einen Media-Upload ist der konkrete Upload-Pfad relevant.
• Keine WordPress-Core-Dateien ändern. Die Fehlermeldung ist ein Symptom der Server- oder Pfadkonfiguration.
• Keine zufälligen wp-config.php-Snippets einfügen. Eine neue UPLOADS-Konstante kann einen zweiten falschen Pfad erzeugen.
• Nicht zuerst sämtliche Plugins deaktivieren. Speicher, Inodes, Site Health, Pfad und Eigentümer lassen sich schneller und mit weniger Risiko prüfen.
• Den Datumsordner nicht abschalten, um den Fehler zu umgehen. Ein nicht beschreibbarer Hauptordner bleibt nicht beschreibbar.

WordPress kann Uploads automatisch nach Jahr und Monat organisieren. Darum nennt die Meldung den aktuellen Zielordner, etwa wp-content/uploads/2026/04. Im nächsten Monat ändert sich der Zahlenwert. Die Diagnose bleibt identisch, weshalb eine einzige zeitlose Anleitung mit /YYYY/MM ausreicht.

755 für Verzeichnisse und 644 für Dateien sind auf vielen Linux-Hostings ein sinnvoller Ausgangspunkt. Entscheidend sind jedoch Eigentümer, Gruppe, ACLs und die Art, wie PHP ausgeführt wird. Wenn dein Hoster andere Werte dokumentiert, gelten dessen Vorgaben.

chmod ändert Rechte, aber nicht Eigentümer und Gruppe. Läuft PHP unter einem anderen Benutzer, ist eine Quote voll oder blockiert open_basedir den Pfad, bleibt der Ordner trotz 755 für den tatsächlichen Prozess unbrauchbar.

Ja. Auch ein volles Inode-Kontingent oder eine Multisite-Quota kann verhindern, dass WordPress die Zieldatei anlegt. Eine Datei von 50 KB kann deshalb scheitern, obwohl sie selbst kaum Platz benötigt.

Normalerweise nicht. Ein überschrittenes upload_max_filesize oder post_max_size erzeugt meist eine eigene Meldung. „Could not be moved“ erscheint später im Ablauf, nachdem die temporäre Datei bereits angenommen wurde. Wenn nur große Dateien scheitern, solltest du beide Fehlerklassen prüfen.

Ja. WordPress versucht den benötigten Upload-Pfad und bei aktiver Datumsstruktur den Jahres- und Monatsordner anzulegen. Scheitert das, ist oft der übergeordnete Ordner nicht beschreibbar oder ein benutzerdefinierter Pfad falsch. Lege Ordner nur manuell an, wenn du Rechte und Eigentümer korrekt übernehmen kannst.

Lade nach jeder Änderung dieselbe kleine Testdatei hoch. So weißt du, welcher Schritt den Fehler behoben hat. Prüfe anschließend die Datei in der Media Library, öffne ihre URL und kontrolliere, ob WordPress die erwarteten Vorschaubilder erzeugt hat.

Wenn der Upload wieder läuft, kannst du die Mediathek in Ruhe aufräumen. neo Rename hilft beim Umbenennen und Verschieben von Medien und aktualisiert Verweise innerhalb von WordPress. Für große Bibliotheken ergänzt neo Library Suche und Organisation, ohne dass du Serverordner von Hand durchsuchen musst.

Quellen: WordPress _wp_handle_upload(), WordPress wp_upload_dir() und WordPress File Permissions.