Dateirechte in WordPress richtig setzen: Verzeichnisse, Dateien und wp-config.php
Welche Dateirechte WordPress braucht, wie Sie sie per SSH prüfen und setzen und wie Sie wp-config.php schützen, ohne Updates und Uploads zu blockieren. Mit echten Fehlermeldungen aus dem Test mit WordPress 7.1.2.
Werbung Mit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Mehr dazu
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.
Voraussetzungen
- WordPress auf einem Linux-Server oder Webspace mit SSH-Zugang (Beispiel: PHP 8.4 unter Apache)
- Rechte, um
chmodund gegebenenfallschownauszuführen;chownerfordert 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- oderchown-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:
| Modell | Typisch bei | Folge |
|---|---|---|
| PHP läuft als Eigentümer der Dateien | Shared Hosting, PHP-FPM mit eigenem Pool je Website | 755/644 genügen, Updates im Backend funktionieren |
| PHP läuft als eigener Webserver-Benutzer | eigener Server mit Apache-Modul oder gemeinsamem PHP-FPM-Pool | Eigentümer und Gruppe müssen bewusst gesetzt werden |
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/uploadsIm Beispiel laufen die Apache-Arbeitsprozesse als www-data, der Hauptprozess als root, und alle WordPress-Dateien gehören 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.
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 lDie letzte Abfrage ist die wichtigste. Steht der Upload-Ordner auf 777, meldet der Befehl 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.
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 {} +In der Regel liefert 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-contentErsetzen 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. Bei einem root-eigenen Plugin-Ordner scheitert 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() ) );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. Die folgenden Kombinationen gelten, wenn Apache und PHP als www-data laufen:
| Eigentümer:Gruppe | Rechte | Website |
|---|---|---|
www-data:www-data | 400 | 200 |
www-data:www-data | 440 | 200 |
root:www-data | 440 | 200 |
root:root | 400 | 500 |
www-data:www-data | 000 | 500 |
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.phpBeachten Sie die Nebenwirkung: Mit 400 oder 440 fehlt normalen Benutzern das Schreibrecht auf die Datei. Ein privilegierter Root-Prozess kann diese Beschränkung umgehen. Deshalb bricht 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). Das hilft vor allem dann, wenn der Webserver durch einen Konfigurationsfehler PHP-Dateien einmal als Text ausliefert.
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. Nach den Änderungen aus den Schritten 1 bis 4 ist der Test 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.
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. Das tritt 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 erscheint, wenn der Upload-Ordner root gehört. 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.
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.
