Bestandsrechten op hosting: chmod 644, 755, 600 en waarom nooit 777

Op shared hosting zet je mappen op 755, bestanden op 644 en wp-config.php op 600 of 640. Alle bestanden horen eigendom te zijn van je hostinggebruiker, want de eigenaar is net zo belangrijk als de cijfers. 777 heb je nooit nodig: op onze testserver draaide een PHP-bestand dat een andere servergebruiker in een map met 777 had gezet met de rechten van de site-eigenaar, en het kon elk bestand van de site overschrijven.

Rechten lezen: drie cijfers, drie klassen

Elk bestand heeft een eigenaar, een groep en aparte rechten voor drie klassen: eigenaar, groep en alle anderen. Lezen is 4, schrijven 2, uitvoeren 1, en elk cijfer is de som daarvan: 7 betekent rwx, 6 rw, 5 r en x, 4 alleen lezen, 0 niets. Het eerste cijfer geldt voor de eigenaar, het tweede voor de groep, het derde voor alle anderen. Deze opdracht toont modi en eigenaren als getallen:

$ stat -c '%a %U:%G %n' wp-config.php index.php wp-content
600 cw8site:cw8site wp-config.php
644 cw8site:cw8site index.php
755 cw8site:cw8site wp-content

Bij een map betekenen dezelfde letters iets anders: r toont de bestanden, w maakt, hernoemt en verwijdert bestanden erin, x geeft toegang tot de map en laat je bestanden openen waarvan je de naam kent. Daarom hebben mappen x nodig en gewone sitebestanden niet: een PHP-script wordt niet als programma gestart, de interpreter leest het alleen. Nog een detail dat in de tests opdook: wie schrijfrecht op een map heeft, kan er bestanden in verwijderen of hernoemen, ook als ze niet van hem zijn.

Rechtentabel: wie mag wat en wanneer gebruik je het

Getest op een testserver waar de bestanden van de sitegebruiker zijn en nginx en Apache als www-data draaien. Voor de webserver vallen je bestanden onder “alle anderen”, dus het derde cijfer bepaalt of hij een afbeelding of stylesheet kan serveren.

Als welke gebruiker draait PHP: de eigenaar of www-data

Dezelfde modi gedragen zich anders afhankelijk van de gebruiker waaronder PHP draait. In een gangbaar hostingpaneel draait elke PHP-FPM-pool als eigenaar van het domein: in het pool-sjabloon staat user = %user%, met www-data als groep van de socket. Oudere opzetten en zelfbeheerde servers laten PHP vaak als www-data draaien, net als de webserver.

Een piepklein bestand laat zien welk geval je hebt. Zet het in de root van de site, open het in een browser en verwijder het meteen weer:

<?php
echo posix_getpwuid(posix_geteuid())['name'], "\n";
echo is_writable(__DIR__ . '/wp-content') ? "wp-content writable\n" : "wp-content NOT writable\n";

Met identieke rechten op de testserver (mappen 755, bestanden 644, eigenaar de sitegebruiker) kregen we dit:

De conclusie: als PHP als eigenaar draait, schrijft WordPress zonder enige 777 in zijn mappen, en 755 plus 644 is alles wat je nodig hebt. De keerzijde: een kwaadaardig script dat op de site belandt, krijgt ook de rechten van de eigenaar. De prioriteit is dus niet de rechten losser zetten, maar zorgen dat zo’n script nooit wordt uitgevoerd.

Wat de webserver serveert: chmod 600 op een afbeelding en op een PHP-bestand

nginx en Apache draaien als www-data. Statische bestanden lezen ze zelf, PHP-bestanden geven ze door aan PHP-FPM, dat ze opent als zijn eigen gebruiker. Dat verklaart een verschil dat je makkelijk voor een bug aanziet:

Apache logt zo’n afbeelding als AH00132: file permissions deny server access, nginx als open() ... failed (13: Permission denied), en PHP-FPM schrijft Unable to open primary script ... (Permission denied). Moet een bestand echt 640 hebben en moet de webserver het lezen, dan moet de groep www-data zijn: met die groep werd de afbeelding met 200 geserveerd. Andere oorzaken van deze statuscode behandelen we in onze gids over de fout 403 Forbidden. Zijn na een verhuizing van de site alleen de afbeeldingen verdwenen terwijl de pagina’s nog openen, controleer dan de modi in wp-content/uploads: een archiefprogramma of FTP-client kan de bestanden met 600 hebben opgeslagen.

Waarom chmod 777 gevaarlijk is: drie tests op de testserver

777 laat elk proces en elke servergebruiker bestanden maken, verwijderen en vervangen. Op de testserver zag dat er zo uit:

1. Andermans bestand draait onder jouw naam. Een andere servergebruiker zette een PHP-bestand in een wp-content met 777. We openden het in een browser en het script draaide als site-eigenaar: het kon wp-config.php lezen en naar index.php schrijven. Met 755 kreeg dezelfde gebruiker “Permission denied”.
2. De beveiliging kan gewoon worden weggehaald. De regel die PHP in uploads blokkeerde, stond in een .htaccess-bestand met modus 644. Maar de map had 777, dus de andere gebruiker hernoemde .htaccess en de test-webshell antwoordde weer met 200. De modus van het bestand zelf hielp niet, want de map bepaalt over verwijderen en hernoemen.
3. 777 zet de deur open voor een kwetsbaar uploadscript. We installeerden bewust een uploadscript zonder controle op de extensie. Met PHP als www-data en uploads op 755 werd shell.php niet opgeslagen: move_uploaded_file(): Unable to move. Na chmod 777 werd het opgeslagen en uitgevoerd.

Nog twee bijwerkingen. WordPress bepaalt de modus van nieuwe mediabestanden aan de hand van de modus van de map, dus in een map met 777 kwamen uploads uit op 666, schrijfbaar voor iedereen. En bestanden die www-data heeft aangemaakt, kan de site-eigenaar niet meer wijzigen: chmod en chown gaven “Operation not permitted”, en alleen een serverbeheerder kan dat oplossen. Op hosting met geïsoleerde accounts kunnen buren meestal niet bij je mappen, maar 777 haalt de laatste verdedigingslinie weg.

PHP-uitvoering in uploads blokkeren

Deze regel helpt ongeacht de rechten: zelfs als er een kwaadaardig bestand in uploads terechtkomt, voert de server het niet uit. Voor Apache, en voor nginx voor Apache, zet je dit .htaccess-bestand in wp-content/uploads:

<FilesMatch "\.(php|phtml|phar)$">
  Require all denied
</FilesMatch>

Voor nginx zonder Apache voeg je dit toe in het server-blok boven de PHP-location, omdat regex-locations op volgorde worden gecontroleerd:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Op de testserver gaven beide regels 403 voor shell.php, terwijl afbeeldingen in dezelfde map nog steeds met 200 werden geserveerd. Meer kant-en-klare regels staan in onze voorbeelden van het .htaccess-bestand.

wp-config.php: 600, 640 of 400

wp-config.php bevat het databasewachtwoord, dus de kernvraag is wie het nog meer kan lezen. Bij 644 las een andere servergebruiker op de testserver zonder moeite de regel DB_PASSWORD.

De WordPress-documentatie raadt 440 of 400 aan (File Permissions, gecontroleerd op 10 november 2026). Draait PHP als jouw gebruiker, gebruik dan 600: de site werkt en buren kunnen het bestand niet lezen. 400 voorkomt bovendien dat scripts het wijzigen, maar sommige cache- en beveiligingsplugins schrijven zelf constanten in wp-config.php en geven dan een foutmelding. Draait PHP als www-data, gebruik dan 640 of 440 met groep www-data. Zonder root kun je een bestand geen groep geven waar je zelf geen lid van bent, dus vraag het aan support. Bij 600 zonder die groep gaf de site een lege 500-pagina, en in het PHP-log stond Failed to open stream: Permission denied in .../wp-load.php. Hoe je zulke antwoorden leest, leggen we uit in ons artikel over de fout 500 Internal Server Error.

umask: waarom nieuwe bestanden 644 krijgen

De modus van een nieuw bestand komt uit de umask, die bits weghaalt van de basis 666 voor bestanden en 777 voor mappen. Op de testserver:

PHP-FPM erft de umask van het proces dat het startte. Toen we de pool met umask 002 startten, kregen bestanden die met file_put_contents werden geschreven 664 en mappen 775. De mediabibliotheek van WordPress gedroeg zich anders: uploads kregen nog steeds 644, omdat WordPress de modus van de bovenliggende map overneemt en het uitvoerbit weghaalt. Precies daarom leidt één 777 op uploads tot 666 op elk nieuw bestand. Via SSH toont umask je masker en zet umask 022 de gebruikelijke waarde voor de sessie terug.

“Could not create directory” in WordPress: controleer de eigenaar

“Could not create directory” bij het installeren of bijwerken van een plugin, en “Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?” bij het uploaden van media wijzen bijna altijd op de verkeerde eigenaar, niet op te strenge rechten. Op de testserver maakten we root eigenaar van wp-content, zoals gebeurt na het uitpakken van een archief als root. PHP dat als site-eigenaar draaide, liep meteen tegen beide fouten aan, en WordPress begon om FTP-gegevens te vragen. Na deze opdracht (user is hier de naam van de site-eigenaar)

chown -R user:user wp-content

werkten uploads en plugin-installaties weer, zonder dat er één modus veranderd hoefde te worden. Installeer je WordPress handmatig, pak het archief dan uit als je eigen gebruiker; de stappen staan in onze handleiding om WordPress op hosting te installeren.

Rechten in bulk herstellen: find-opdrachten

Maak via SSH verbinding met je hosting, ga naar de root van de site en voer uit:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +
chmod 600 wp-config.php

We hebben drie methoden getimed op een WordPress-boom met 2.777 bestanden en 284 mappen, waarbij we vóór elke run alles op 777 zetten. Elke methode draaide drie keer als site-eigenaar:

Op een grote site merk je een verschil van een factor honderd, dus gebruik de vorm met de plus. Deze opdrachten vinden probleembestanden:

find . -perm -o+w              # writable by anyone
find . -type f -perm /111      # files with the execute bit
find . ! -user $(whoami) -ls   # files owned by another user

Vindt de laatste opdracht bestanden van www-data of root, dan werkt chmod daar niet op: op de testserver stopte het herstel in bulk bij een bestand van www-data met “Operation not permitted”. Zonder SSH wijzig je de rechten in het bestandsbeheer van het paneel of in FileZilla: het item “Bestandsrechten” in het contextmenu kan een modus recursief toepassen, alleen op mappen of alleen op bestanden.

chown: wie de eigenaar mag wijzigen

Alleen root kan de eigenaar van een bestand wijzigen. Op de testserver eindigde de poging van de sitegebruiker om een bestand aan een andere gebruiker over te dragen met “Operation not permitted”. Op shared hosting heb je geen root, dus bestanden met een vreemde eigenaar worden hersteld door support of via een functie van het paneel. Bij de hostingpakketten van RichHost beheer je sites in ons eigen controlepaneel met AI-assistent, en support werkt van 10:00 tot 20:00 Kyivse tijd en antwoordt meestal binnen 30 minuten.

Veelgestelde vragen

Welke rechten heeft WordPress nodig?

Mappen 755, bestanden 644, wp-config.php 600. Draait PHP als www-data, dan heeft wp-config.php 640 of 440 nodig met groep www-data. Alle bestanden horen van jouw gebruiker te zijn.

Waarom laadt een afbeelding niet meer na chmod 600 terwijl de pagina werkt?

De webserver leest de afbeelding als www-data, en een bestand met 600 is voor hem afgesloten, dus antwoordt hij met 403. Het PHP-bestand wordt geopend door PHP-FPM, dat als eigenaar draait, en daarvoor is 600 genoeg.

Hebben PHP-bestanden 755 nodig?

Nee. De interpreter leest een PHP-script alleen en heeft het uitvoerbit niet nodig. 755 is voor mappen en voor shellscripts die je met de hand of via cron start.

WordPress vraagt om FTP-gegevens bij het installeren van een plugin. Wat is er mis?

PHP kan niet naar de bestanden van de site schrijven, omdat het als een andere gebruiker draait of omdat de bestanden een andere eigenaar hebben. Op de testserver leverden beide gevallen precies deze vraag op. Herstel de eigenaar in plaats van 777 in te stellen.

Zijn 775 en 664 veilig?

Ze geven de groep schrijfrecht. Ben je het enige lid van de groep, dan is het risico klein, maar er is ook geen voordeel: als PHP als eigenaar draait, is schrijfrecht voor de groep niet nodig. Blijf bij 755 en 644.