File permissions in WordPress: juiste rechten voor wp-config en wp-content

Krijg je een “kan niet uploaden”-fout in WordPress? Of valt een plugin-update halverwege uit met de boodschap dat de map niet beschrijfbaar is? In negen van de tien gevallen klopt er iets niet met de file permissions. De rechten op bestanden of mappen staan te streng, of juist te ruim.

Dit artikel laat zien welke rechten WordPress nodig heeft. 644 voor bestanden, 755 voor mappen, 600 voor wp-config.php. Plus de commando’s om dat in te stellen via SSH of FTP, en een troubleshooting-volgorde voor de meest voorkomende foutmeldingen.

Ik werk vanuit Terneuzen aan onderhoud en hardening van WordPress-sites. File permissions horen bij de basis-hardening na een migratie of een hack. Vaak een kwartiertje werk, maar makkelijk over het hoofd gezien.

Wat file permissions zijn

Op Linux- en Unix-servers (waarop vrijwel elke WordPress-site draait) heeft elk bestand drie groepen rechten. Voor de eigenaar (user), voor de groep, en voor alle anderen (world). Per groep zijn er drie acties mogelijk: lezen, schrijven en uitvoeren.

In de chmod-notatie krijgen die acties een nummer:

• Lezen = 4
• Schrijven = 2
• Uitvoeren = 1

Optellen geeft de combinatie. 644 betekent: eigenaar mag lezen en schrijven (6 = 4+2), groep en wereld mogen alleen lezen (4). Voor mappen voegt 1 het recht toe om de inhoud te bekijken, dus 755 = 7 voor eigenaar, 5 voor groep en wereld.

Officiële WordPress-documentatie staat op de hardening WordPress-pagina. Daar staan dezelfde nummers als hieronder, met meer technische achtergrond.

De juiste rechten voor WordPress

Drie waardes om te onthouden. Niet meer.

644 voor bestanden. Alle PHP-bestanden in WordPress core, je thema’s en plugins. Eigenaar leest en schrijft, anderen alleen lezen. Web-bezoekers (die als “anderen” tellen) kunnen het bestand laten uitvoeren door de webserver, maar niet wijzigen.

755 voor mappen. Alle directories in een WordPress-installatie. Eigenaar mag alles, anderen mogen lezen en de mapinhoud bekijken. Zonder execute-recht op mappen kun je niet door de structuur navigeren, ook niet binnen de webserver.

600 voor wp-config.php. Het bestand met databasewachtwoord en security keys. Alleen leesbaar en schrijfbaar voor de eigenaar. Andere accounts op de server kunnen het niet eens openen.

Op shared hosting werkt 600 niet altijd, omdat de webserver soms onder een ander account draait dan jouw FTP-user. In dat geval is 640 het maximum dat werkt, of in extreme gevallen 644. Liever 644 dan een onbereikbare site.

SSH-commando’s om alles in één keer goed te zetten

Heb je SSH-toegang tot de server, dan zijn dit de commando’s. Voer ze uit vanuit de WordPress-rootmap (de plek waar wp-config.php staat).

Eerst alle bestanden naar 644:

bash

find . -type f -exec chmod 644 {} \;

Daarna alle mappen naar 755:

bash

find . -type d -exec chmod 755 {} \;

Tot slot wp-config.php apart:

bash

chmod 600 wp-config.php

Werkt 600 niet (de site geeft een fout), dan terugzetten naar 640 of 644:

bash

chmod 640 wp-config.php

Voor .htaccess geldt hetzelfde patroon. 644 is standaard. Sommige hosters draaien .htaccess op 444 om wijzigingen te voorkomen, dat werkt ook maar maakt edits via WordPress onmogelijk.

FTP-commando’s via FileZilla

Geen SSH? Dan werkt het via FTP. FileZilla is de meest gebruikte client. Voor wie liever met een UI werkt.

In FileZilla, na verbinden met de site:

1. Navigeer naar de WordPress-rootmap
2. Selecteer alle bestanden en mappen
3. Rechtsklik > Bestandsattributen
4. Vink “Doorgeven aan submappen” aan
5. Kies “Toepassen op bestanden” en zet 644
6. Klik OK
7. Herhaal de actie, dit keer “Toepassen op mappen” en zet 755

Daarna apart op wp-config.php:

1. Rechtsklik op het bestand
2. Bestandsattributen > 600 invullen
3. OK

Dit duurt op een gemiddelde site ongeveer vijf tot tien minuten. FTP is trager dan SSH omdat elk bestand individueel wordt aangepast. Bij grote sites met duizenden afbeeldingen kan het oplopen.

Een waarschuwing: zet nooit alle bestanden in één klap op 777. Dat geeft schrijfrecht aan iedereen op de server, ook aan kwaadaardige scripts. 777 is een rode vlag in elke security-audit en is bijna nooit nodig.

wp-content en uploads-map apart

De map wp-content/uploads/ is bijzonder. WordPress moet daar bestanden in kunnen schrijven (afbeeldingen, PDF’s, media). Andere bestanden in de site mogen daar geen rechten op hebben.

Voor de uploads-map zelf:

bash

chmod 755 wp-content/uploads

Sommige hosters draaien onder een setup waar 755 niet voldoende is voor schrijven. In dat geval kan 775 nodig zijn:

bash

chmod 775 wp-content/uploads

755 of 775 is acceptabel. 777 vermijden, ook hier.

Voor wp-content zelf werkt 755 prima. Plugins die hun eigen mappen aanmaken in wp-content/plugins/ doen dat met de juiste rechten als de eigenaar van de installatie correct is.

Wie wil weten of er ergens iets verkeerd staat: dit commando toont alle bestanden met afwijkende permissions:

bash

find . -type f -not -perm 644
find . -type d -not -perm 755

Krijg je een lijst terug, dan staan daar de uitzonderingen. Soms zijn die met reden (een plugin die specifieke rechten vereist), vaak zijn ze een restant van een vorige migratie of een gepatchte hack.

Veelvoorkomende foutmeldingen

Vier symptomen die op verkeerde permissions wijzen.

“Sorry, this file type is not permitted for security reasons” of “Kan niet uploaden”. Vaak ligt dit niet aan permissions, maar aan een MIME-type-filter. Maar in een aantal gevallen is de uploads-map niet beschrijfbaar. Controleer de rechten op wp-content/uploads.

“Update failed: Could not create directory”. Bij een plugin-update kan WordPress de tijdelijke map niet aanmaken. De rechten op wp-content of wp-content/upgrade staan te streng. Vaak helpt 755 op die map.

Plugin-installatie vraagt om FTP-credentials. Een teken dat de eigenaar van de bestanden niet overeenkomt met de PHP-user. Te streng ingesteld, of een verkeerde owner na een migratie. Hier is chown nodig, niet alleen chmod. Hoster contacteren of via SSH met chown -R webserver:webserver . aanpassen.

Witte pagina na chmod-actie. Te streng. Bestanden hebben geen leesrecht meer voor de webserver. Snel terugzetten naar 644 voor bestanden en 755 voor mappen, anders is je site offline.

Wat na een hack of migratie

Na een gehackte site of een migratie van hoster is permissions opnieuw zetten een vast onderdeel van de cleanup. Aanvallers zetten soms bestanden op afwijkende rechten om hun toegang te behouden. Een nieuwe chmod 644/755-pas wist die patronen.

Volgorde die ik gebruik bij hardening na een incident:

1. Eerst back-up maken (altijd)
2. Alle bestanden naar 644, mappen naar 755
3. wp-config.php naar 600 (of 640 als 600 niet werkt)
4. Eigenaar (owner) controleren met ls -la
5. Eventueel chown om de eigenaar te corrigeren
6. Daarna de site testen op alle hoofdfuncties

Voor klanten met een WordPress onderhoudscontract hoort dit bij de standaard-hardening bij de start. Geen extra factuur. Bij Onderhoud Plus (€175 per maand) loopt er ieder kwartaal een controle of de permissions nog kloppen, want plugins of updates kunnen ze soms wijzigen.

Voor losse WordPress hulp bij een fout op je site, reken ik per uur. Standaard €70, spoed €105. Migratie en serverwerk valt onder €95 per uur.

Geen 24/7-support. Spoedwerk in overleg.

Wanneer je een hoster moet inschakelen

Sommige situaties zijn niet via SSH of FTP op te lossen. Drie scenario’s waarin je beter de hoster vraagt.

Verkeerde eigenaar van de bestanden. Als alle bestanden van een vorige FTP-account zijn, niet van de huidige webserver, dan moet chown worden uitgevoerd. Dat vereist root-toegang, die je op shared hosting niet hebt.

SELinux-issues op een VPS. Sommige beheerde VPS-omgevingen hebben SELinux actief, wat een extra laag bovenop permissions legt. Daar moet chcon of setsebool worden gebruikt, niet chmod.

Hosters met een aangepaste PHP-handler. Hosters die FastCGI of mod_php in afwijkende setups draaien, kunnen permissions afdwingen die niet via FTP wijzigbaar zijn. Een ticket bij support is sneller dan zelf experimenteren.

In de praktijk zit dit vooral bij goedkope shared-hosters of bij sites die al meerdere keren tussen partijen zijn verhuisd. Hostinger, SiteGround en de gangbare Nederlandse hosters hebben dit doorgaans goed staan zodra de site eenmaal werkt.

Heb je een foutmelding die niet weggaat, of twijfel je over wat veilig is? Stuur me de tekst van de fout en je hoster. Ik kijk en mail terug. Meer artikelen staan in de categorie website beveiliging.