Dateirechte in WordPress richtig setzen: Verzeichnisse, Dateien und wp-config.php

Falsche Dateirechte sind bei WordPress eine häufige Ursache für zwei gegensätzliche Probleme. Sind sie zu offen, etwa 777 auf dem Upload-Ordner, kann jeder Prozess auf dem Server Dateien ändern und Schadcode ablegen. Sind sie zu streng oder gehören die Dateien dem falschen Benutzer, scheitern Updates, Uploads schlagen fehl, und im schlimmsten Fall zeigt die Website nur noch einen Fehler 500. Diese Anleitung erklärt, welche Rechte WordPress braucht, wie Sie sie per SSH prüfen und setzen und wie Sie wp-config.php zusätzlich schützen. Alle Befehle und die gezeigten Fehlermeldungen stammen aus einer Testinstanz mit WordPress 7.1.2 unter Apache.

Voraussetzungen

• WordPress auf einem Linux-Server oder Webspace mit SSH-Zugang (getestet mit WordPress 7.1.2, PHP 8.4, Apache)
• Rechte, um chmod und gegebenenfalls chown auszuführen; chown erfordert meist root oder sudo und ist bei Shared Hosting oft nicht möglich
• Benutzerkonto mit der Rolle Administrator im WordPress-Backend für die Prüfung unter „Website-Zustand“
• Grundkenntnisse zu Linux-Rechten, siehe Linux-Benutzer, Gruppen und Rechte verstehen
• Ein aktuelles Backup der Dateien, denn ein falscher chmod- oder chown-Befehl über das ganze Verzeichnis lässt sich ohne Backup nur mühsam rückgängig machen
• Ohne SSH: Ein SFTP-Programm, das Rechte setzen kann; die Eigentümerfrage klären Sie dann mit dem Hoster

Schritt 1: Herausfinden, unter welchem Benutzer PHP läuft

Die Rechte-Zahl allein sagt wenig. Ob WordPress eine Datei lesen oder schreiben darf, hängt davon ab, wem sie gehört und unter welchem Benutzer PHP läuft. Es gibt zwei verbreitete Modelle:

Auf einem eigenen Server finden Sie den Benutzer so heraus:

ps -o user= -C apache2 | sort | uniq -c   # Apache (Debian/Ubuntu)
ps -o user= -C php-fpm8.4 | sort | uniq -c # PHP-FPM, Versionsnummer anpassen
stat -c "%a %U:%G %n" wp-config.php wp-content wp-content/uploads

In der Testinstanz liefen die Apache-Arbeitsprozesse als www-data, der Hauptprozess als root, und alle WordPress-Dateien gehörten www-data:www-data mit 755 bzw. 644. Das ist das erste Modell. WordPress selbst prüft beim Aktualisieren, ob es Dateien direkt schreiben kann. Das Ergebnis zeigt dieser Befehl:

wp eval 'require_once ABSPATH . "wp-admin/includes/file.php"; echo get_filesystem_method();'

Die Ausgabe direct bedeutet: WordPress schreibt Updates ohne FTP-Zugangsdaten. Fragt WordPress im Backend bei Updates nach FTP-Daten, passt der Eigentümer der Dateien nicht zum PHP-Benutzer.

Verifizieren: Sie kennen den PHP-Benutzer und den Eigentümer der WordPress-Dateien und wissen, welches Modell bei Ihnen gilt.

Schritt 2: Ist-Zustand prüfen und Ausreißer finden

Bevor Sie etwas ändern, suchen Sie Abweichungen. Wechseln Sie ins WordPress-Hauptverzeichnis und führen Sie aus:

cd /var/www/html   # Pfad anpassen

# Verzeichnisse, die nicht 755 haben
find . -type d ! -perm 755

# Dateien, die nicht 644 haben
find . -type f ! -perm 644

# Alles, was für jeden beschreibbar ist
find . -perm -o+w -not -type l

Die letzte Abfrage ist die wichtigste. Im Test hatten wir den Upload-Ordner absichtlich auf 777 gesetzt, und der Befehl meldete genau ./wp-content/uploads. Jeder Eintrag in dieser Liste ist ein Befund: Auf einem Server mit mehreren Benutzern oder Websites könnte jeder andere Prozess dort Dateien ablegen, auch PHP-Dateien. Die offizielle Dokumentation von WordPress ist hier eindeutig: Kein Verzeichnis sollte jemals 777 erhalten, auch Upload-Verzeichnisse nicht.

Abweichungen von 755 und 644 sind nicht automatisch falsch. Manche Plugins legen Cache-Ordner mit eigenen Rechten an, und 750 bzw. 640 sind strenger und damit zulässig. Notieren Sie die Funde und entscheiden Sie einzeln.

Verifizieren: find . -perm -o+w -not -type l liefert keine Ausgabe, oder Sie haben jeden Fund notiert und begründet.

Schritt 3: Standardrechte für Verzeichnisse und Dateien setzen

Die empfohlenen Werte aus dem Advanced Administration Handbook von WordPress lauten: Verzeichnisse 755 oder 750, Dateien 644 oder 640. Setzen Sie sie getrennt, denn Verzeichnisse brauchen das Ausführungsrecht, damit man sie betreten kann, Dateien dagegen nicht. Ein pauschales chmod -R 644 sperrt alle Verzeichnisse und legt die Website lahm.

cd /var/www/html   # Pfad anpassen
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

Im Test lieferte die Website danach unverändert Status 200. Gehören die Dateien nicht dem PHP-Benutzer und haben Sie root-Rechte, korrigieren Sie auch den Eigentümer. Im ersten Modell aus Schritt 1 lautet der Befehl zum Beispiel:

sudo chown -R www-data:www-data /var/www/html/wp-content

Ersetzen Sie www-data durch den PHP-Benutzer Ihres Systems. Führen Sie chown -R nie auf ein höher liegendes Verzeichnis aus, als Sie meinen: Ein Tippfehler im Pfad kann Systemdateien einem Webserver-Benutzer übertragen.

Wer das zweite Modell strenger umsetzt, lässt die Kerndateien einem eigenen Deploy-Benutzer gehören und gibt dem PHP-Benutzer nur Schreibrechte auf wp-content oder sogar nur auf wp-content/uploads. Das begrenzt den Schaden, wenn ein Angreifer über ein Plugin PHP-Code ausführt. Der Preis: Updates im Backend funktionieren dann nicht mehr. Im Test mit einem root-eigenen Plugin-Ordner scheiterte wp plugin install mit Warning: Das Verzeichnis konnte nicht erstellt werden. Updates spielen Sie dann per WP-CLI als Eigentümer ein, siehe WordPress-Updates per WP-CLI. Für kleine Unternehmen ohne eigene Administration ist das erste Modell meist die ehrlichere Wahl, weil Updates dann zuverlässig laufen.

Bei Plugins, die Dateien mit eigenen Rechten anlegen, können Sie die Standardwerte in wp-config.php vorgeben. Die Konstanten FS_CHMOD_DIR und FS_CHMOD_FILE überschreiben laut Dokumentation die Rechte, die WordPress beim Schreiben verwendet:

define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

Verifizieren: find . -type d ! -perm 755 und find . -type f ! -perm 644 liefern nur noch bewusst begründete Ausnahmen, die Startseite lädt, ein Test-Upload unter Medien gelingt.

Schritt 4: wp-config.php zusätzlich schützen

wp-config.php enthält die Zugangsdaten zur Datenbank und die Schlüssel für Anmelde-Cookies. Die WordPress-Dokumentation empfiehlt dafür 440 oder 400, damit andere Benutzer auf dem Server sie nicht lesen können. Wichtig ist, dass PHP die Datei weiterhin lesen kann. Wir haben in der Testinstanz, in der Apache und PHP als www-data laufen, mehrere Kombinationen ausprobiert:

Die Tabelle zeigt die Regel: Entweder gehört die Datei dem PHP-Benutzer, oder dessen Gruppe hat Leserecht. Setzen Sie die Rechte im ersten Modell so:

chmod 400 wp-config.php
stat -c "%a %U:%G" wp-config.php

Beachten Sie die Nebenwirkung: Mit 400 oder 440 kann niemand mehr die Datei per WP-CLI ändern, auch Sie nicht. Im Test brach wp config set mit Reason: wp-config.php is not writable. ab. Für eine Änderung setzen Sie die Datei kurz auf 600, ändern sie und stellen danach wieder 400 ein.

Zusätzlich können Sie wp-config.php eine Ebene über das WordPress-Verzeichnis verschieben. WordPress sucht sie dort automatisch, sofern im übergeordneten Verzeichnis keine wp-settings.php einer anderen Installation liegt (geprüft in wp-load.php von 7.1.2). Das hilft vor allem dann, wenn der Webserver durch einen Konfigurationsfehler PHP-Dateien einmal als Text ausliefert.

Verifizieren: stat -c "%a %U:%G" wp-config.php zeigt 400 oder 440 mit passendem Eigentümer bzw. passender Gruppe, die Startseite liefert Status 200, die Anmeldung im Backend funktioniert.

Schritt 5: Ergebnis im Backend prüfen und dauerhaft überwachen

Öffnen Sie Werkzeuge > Website-Zustand. Der Test für Hintergrundaktualisierungen prüft, ob WordPress seine Dateien beschreiben kann und ob es FTP-Zugangsdaten braucht. In der Testinstanz war der Test nach allen Änderungen bestanden, einschließlich der Prüfung, dass keine FTP-Zugangsdaten nötig sind. Wenn Sie das strenge Modell gewählt haben, meldet WordPress hier erwartungsgemäß nicht beschreibbare Dateien; das ist dann kein Fehler, sondern Ihre Entscheidung, die Sie dokumentieren.

Laden Sie zum Abschluss ein Testbild unter Medien hoch und aktualisieren Sie, falls vorhanden, ein Plugin. Beides zeigt, ob die Schreibrechte dort stimmen, wo WordPress sie braucht.

Dateirechte bleiben nicht von selbst korrekt. Plugins legen neue Ordner an, ein Umzug oder eine Wiederherstellung aus dem Backup übernimmt die Rechte der Quelle, und bei der Fehlersuche setzt jemand „nur kurz“ 777. Nehmen Sie die Abfrage aus Schritt 2 deshalb in Ihren monatlichen Wartungsplan für WordPress auf. Wer solche Kontrollen und die Updates nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung der Firewall.

Verifizieren: Unter Werkzeuge > Website-Zustand erscheint der Test für Hintergrundaktualisierungen bei den bestandenen Tests, oder die Abweichung ist dokumentiert. Test-Upload und Plugin-Update gelingen.

Typische Fehler

Fehler 500 nach Änderung an wp-config.php: PHP kann die Datei nicht mehr lesen. Im Test trat das bei root:root mit 400 und bei 000 auf. Geben Sie dem PHP-Benutzer die Datei zurück oder Leserecht über die Gruppe.

„Die hochgeladene Datei konnte nicht nach wp-content/uploads/2026/09 verschoben werden.“: Diese Meldung erschien im Test, als der Upload-Ordner root gehörte. Setzen Sie den Eigentümer von wp-content/uploads auf den PHP-Benutzer, nicht die Rechte auf 777.

„Das Verzeichnis konnte nicht erstellt werden.“ bei Plugin-Installation oder Update: Der PHP-Benutzer darf in wp-content/plugins nicht schreiben. Entweder Eigentümer korrigieren oder Updates bewusst per WP-CLI als Eigentümer durchführen.

WordPress fragt bei Updates nach FTP-Zugangsdaten: get_filesystem_method() liefert nicht direct, weil die Dateien einem anderen Benutzer gehören als PHP. Geben Sie keine FTP-Daten im Backend ein, sondern korrigieren Sie den Eigentümer.

Website nach chmod -R 644 komplett weg: Verzeichnisse haben das Ausführungsrecht verloren. Führen Sie den find-Befehl für Verzeichnisse aus Schritt 3 aus.

Häufige Fragen

Ist 755 für Verzeichnisse nicht zu offen?

755 erlaubt allen Benutzern Lesen und Betreten, aber nur dem Eigentümer das Schreiben. Auf einem Server, auf dem nur Ihre Website läuft, ist das unkritisch. Bei gemeinsam genutzten Servern sind 750 und 640 strenger, sofern der Webserver über die Gruppe Zugriff hat.

Kann ich die Rechte ohne SSH setzen?

Die Zahlen ja, mit einem SFTP-Programm. Den Eigentümer ändern Sie ohne SSH meist nicht; klären Sie das mit dem Hoster. Bei den meisten Webhosting-Tarifen läuft PHP ohnehin als Ihr Benutzer, dann genügen 755 und 644.

Schützen korrekte Dateirechte vor Hackerangriffen?

Sie begrenzen den Schaden, verhindern aber keine Lücke in einem Plugin. Aktuelle Software und Backups bleiben die Grundlage.

Testumfang

Wir haben alle Schritte am 30.09.2026 in einer isolierten Testumgebung mit WordPress 7.1.2 unter Apache durchgespielt, wobei PHP als www-data lief. Dazu gehörten auch Uploads und Plugin-Installationen bei falschem Dateieigentümer sowie mehrere Varianten der wp-config.php.

Nicht geprüft haben wir Nginx mit PHP-FPM und eigenen Pools. Dort gelten dieselben Regeln, nur mit anderen Benutzernamen, also passen Sie diese an und testen Sie vorher auf einer Kopie.

Fazit

Richtige Dateirechte bei WordPress bedeuten 755 für Verzeichnisse, 644 für Dateien, 400 oder 440 für wp-config.php und vor allem den richtigen Eigentümer. Prüfen Sie nach jeder Änderung sofort Website, Upload und Updates, und suchen Sie regelmäßig nach für jeden beschreibbaren Dateien. 777 ist nie die Lösung. Wenn Sie die laufende Pflege abgeben möchten, übernimmt die WordPress-Wartung von Marcel Schönfelder Updates, Backups und Firewall.

Weiterführende Anleitungen und Quellen

• Linux-Benutzer, Gruppen und Rechte verstehen
• WordPress-Updates per WP-CLI
• Wartungsplan für WordPress
• Advanced Administration Handbook: Changing File Permissions
• Advanced Administration Handbook: Hardening WordPress
• Advanced Administration Handbook: wp-config.php