Filrettigheder i WordPress — hvad 644 og 755 betyder

Kort svar: De rigtige WordPress filrettigheder er 644 på filer og 755 på mapper, og wp-config.php kan med fordel strammes til 640 eller 600. Virker opdateringer eller uploads ikke med de værdier, er det næsten altid ejerskabet, der er forkert – ikke rettighederne. Brug aldrig 777: det løser intet, som rigtigt ejerskab ikke løser bedre, og det åbner for, at andre kan skrive i dine filer.

Fagligt gennemgået: 2. oktober 2026

De rigtige filrettigheder i WordPress er 644 på filer og 755 på mapper. Undtagelsen er wp-config.php, som med fordel kan sættes til 640 eller 600. Er de strammere, kan WordPress ikke opdatere sig selv. Er de løsere, kan andre skrive i dine filer.

Denne guide forklarer, hvad tallene betyder, hvordan du sætter dem rigtigt, og hvordan du fejlfinder, når WordPress alligevel melder “Could not create directory”, beder om FTP-oplysninger eller giver en 500-fejl efter en chmod.

Før du ændrer noget: Notér de nuværende rettigheder og ejere, før du ændrer dem rekursivt – en forkert rekursiv kommando på hele kontoen kan gøre sitet utilgængeligt. Kør aldrig chmod -R 777 “for at teste”. Har du fundet filer med 777 eller 666, du ikke selv har sat, så behandl det som et muligt sikkerhedsproblem og tag en backup, før du rydder op.

Hvad tallene betyder

Hvert ciffer står for én gruppe: ejeren, gruppen og alle andre. Værdien er summen af læse (4), skrive (2) og udføre (1).

Værdi	Ejer	Gruppe	Alle andre	Bruges til
644	læse + skrive	læse	læse	Almindelige filer, fx PHP, CSS og billeder
755	alt	læse + åbne	læse + åbne	Mapper
640	læse + skrive	læse	intet	wp-config.php
600	læse + skrive	intet	intet	wp-config.php, når PHP kører som ejeren
777	alt	alt	alt	Aldrig

At en mappe skal have “udfør” lyder mærkeligt, men det er dét, der giver lov til at åbne den. Uden det kan filerne indeni ikke nås, selv om de selv har de rigtige rettigheder.

Symptomer på forkerte rettigheder eller forkert ejerskab

Symptom	Sandsynlig årsag	Første kontrol
“Could not create directory” ved opdatering eller upload	PHP må ikke skrive i mappen – oftest forkert ejer	Ejer af wp-content og undermapper
WordPress beder om FTP-oplysninger ved opdatering	Filerne ejes af en anden bruger end PHP	Webstedstilstand → Filsystemtilladelser
500-fejl lige efter en chmod	Serveren nægter at køre filer, som alle kan skrive i	Søg efter 777/666 og fejlloggen
Permalinks giver 404 efter ændring	.htaccess kan ikke skrives	Rettigheder og ejer på .htaccess
Hvid skærm eller kritisk fejl efter at have strammet wp-config.php	PHP kan ikke længere læse filen	Sæt 640 i stedet for 600, eller tjek ejer
Billeder uploades, men vises ikke	Filerne er oprettet med for stramme rettigheder	Rettigheder på filerne i uploads

1. Se de nuværende rettigheder og ejere

I WordPress kan du under Værktøjer → Webstedstilstand → Info → Filsystemtilladelser se, om WordPress kan skrive i de vigtigste mapper. Står der “Ikke skrivbar” ved wp-content, uploads eller plugins, har du fundet stedet. Har du SSH, giver kommandolinjen det fulde billede:

ls -la /sti/til/sitet
ls -la /sti/til/sitet/wp-content
stat -c '%a %U:%G %n' /sti/til/sitet/wp-config.php

Kig både på tallene og på ejeren. Står nogle filer med en anden ejer end resten – fx root eller en webserverbruger – er det typisk efter en upload med en anden konto, en gendannelse eller en manuel kommando kørt som administrator.

2. Sæt rettighederne rigtigt

I filhåndteringen i kontrolpanelet vælger du mappen, vælger rettigheder og sætter flueben i at anvende rekursivt – med hver sin værdi for filer og mapper.

wp-content/        755
wp-content/*.php   644
wp-config.php      640

Med kommandolinjen – rigtigt første gang

Har du SSH, så lad være med at sætte 755 på alt og 644 bagefter i hånden. To kommandoer med find rammer præcis mapper og filer hver for sig, uanset hvor mange der er:

find /sti/til/sitet -type d -exec chmod 755 {} \;
find /sti/til/sitet -type f -exec chmod 644 {} \;
chmod 640 /sti/til/sitet/wp-config.php

Bagefter kan du kontrollere resultatet med find /sti/til/sitet -perm 777 – kommandoen skal ikke finde noget. Finder den mapper, er det som regel et plugin, der selv har sat dem ved installation (cache- og backup-plugins er de typiske), og de bør også ned på 755.

3. Når rettighederne er rigtige, men det stadig ikke virker

Så er det ejerskabet, ikke rettighederne. Filerne skal ejes af den bruger, PHP kører som. Med 755 må kun ejeren skrive i en mappe – er ejeren en anden end PHP-processen, kan WordPress ikke oprette filer, uanset hvor tit du kører chmod.

Et tydeligt tegn er, at WordPress beder om FTP-værtsnavn, brugernavn og adgangskode, når du opdaterer et plugin. Det gør WordPress, når den prøver at skrive en testfil og opdager, at filen får en anden ejer end WordPress’ egne filer. Løsningen er at rette ejeren – ikke at indtaste FTP-oplysninger eller tvinge metoden med define( 'FS_METHOD', 'direct' );, som blot giver nye fejl, hvis ejeren stadig er forkert.

Med root-adgang rettes ejerskabet med chown:

chown -R sitebruger:sitebruger /sti/til/sitet

På et webhotel har du sjældent den adgang – så er det hostingens support, der skal rette det. Se også could not create directory, som går i dybden med netop den fejl.

4. Kontrollér, hvilke rettigheder WordPress selv opretter filer med

Bliver nye uploads eller opdaterede plugins ved med at få forkerte rettigheder, så er det enten serverens umask eller en indstilling i wp-config.php. WordPress har to konstanter til formålet, og de skal normalt ikke være sat. Er de sat til noget andet end standarden, så ret dem eller fjern dem:

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

Søg samtidig efter FS_METHOD, FTP_USER og lignende linjer, som en tidligere udvikler kan have efterladt. Gamle FTP-indstillinger i wp-config.php er en klassisk årsag til, at opdateringer fejler efter en flytning.

Hvad WordPress selv har brug for at skrive i

WordPress skriver kun få steder under normal drift: wp-content/uploads ved hver upload, wp-content/plugins og wp-content/themes ved installation og opdatering, wp-content/upgrade som midlertidig mappe under opdateringer, og cache-mapper fra dit cacheplugin. Alt andet – wp-admin, wp-includes og filerne i roden – skal kun kunne skrives ved en kerneopdatering. .htaccess skal kunne skrives, når du gemmer permalinks. Det betyder også, at hvis rettighederne er 755/644 og ejeren er rigtig, så virker alt; du behøver aldrig åbne mere op for at få et plugin til at fungere.

På servere, hvor PHP kører som sitets egen bruger (suEXEC, LiteSpeed med “run as user” eller en isoleret container pr. site), er 644 og 755 præcis nok, fordi ejeren og PHP-processen er den samme. Det er den opsætning, moderne hosting bruger, og den er grunden til, at 777 aldrig er nødvendigt.

640 eller 600 på wp-config.php?

600 betyder, at kun ejeren kan læse filen. Det virker, når PHP kører som ejeren. Kører PHP som en anden bruger i samme gruppe, kan den ikke læse filen, og sitet stopper med en fatal fejl. Så er 640 det rigtige valg. Start med 640, test sitet, og gå kun til 600, hvis du ved, at PHP kører som filens ejer.

Hvorfor 777 er en dårlig idé

Det er en af de klassiske årsager til, at én hacket side smitter andre på samme server. Har alle skriveadgang, kan et script fra et helt andet site eller en anden brugerkonto lægge filer ind hos dig.

Mange servere afviser derfor 777 helt. På opsætninger med suEXEC eller lignende nægter serveren at køre PHP-filer eller mapper, som gruppen eller alle andre kan skrive i, og svarer med en 500-fejl. Har du fået en 500 Internal Server Error lige efter at have “åbnet” rettighederne, så sæt dem tilbage til 755/644 – det er tit hele løsningen.

Rettigheder som sikkerhedslag

Rigtige rettigheder er ikke kun et spørgsmål om, at opdateringer virker. De begrænser også, hvad et kompromitteret plugin kan gøre. Tre greb, der er gratis at tage: sæt wp-config.php til 640, så andre brugere på serveren ikke kan læse databasekoden; slå filredigering fra i administrationen med define( 'DISALLOW_FILE_EDIT', true );, så en stjålet administratorkonto ikke kan skrive PHP direkte i temaet; og bloker PHP-kørsel i uploads-mappen, så en fil, der er sneget ind som “billede”, ikke kan køres. Det sidste sættes i webserverens konfiguration og hører med i en ordentlig sikkerhedsopsætning fra hostens side. Se også wp-config-hærdning.

Ser du pludselig filer med rettigheder som 666 eller 777, som du ikke selv har sat, så er det værd at undersøge. Skadelig kode sætter ofte rettighederne op, så den kan skrive til sine egne filer senere – en scanning for ændrede filer er næste skridt, ikke bare en chmod:

find /sti/til/sitet -type f \( -perm -o+w -o -perm -g+w \)
find /sti/til/sitet/wp-content/uploads -name "*.php"
wp core verify-checksums

Den første kommando finder filer, som gruppen eller alle andre kan skrive i. Den anden finder PHP-filer i uploads, hvor der normalt ingen skal være. Den tredje sammenligner WordPress’ kernefiler med de officielle. Finder du noget, så følg malware-oprydning i WordPress.

Verificér, at alt er i orden

• find /sti/til/sitet -perm 777 finder ingenting.
• Webstedstilstand → Filsystemtilladelser viser “Skrivbar” ved wp-content, uploads, plugins og temaer.
• Du kan uploade et billede og opdatere et plugin uden at blive bedt om FTP-oplysninger.
• Forsiden og wp-admin virker efter ændringen af wp-config.php.
• Gem permalinks én gang, og test en underside – så ved du, at .htaccess kan skrives.

Hvornår skal hostingen hjælpe?

Ejerskab, umask og hvilken bruger PHP kører som, styres af serveren. Kan du ikke selv rette ejeren, eller kommer de forkerte rettigheder igen efter hver opdatering, så kontakt supporten med en liste over de mapper, der fejler, og den præcise fejlbesked. På WordPress hosting hos Hostious kan du få dansk support døgnet rundt til netop den slags.

Læs også

• Hub: WordPress fejl og fejlfinding
• “Could not create directory” – når WordPress ikke må skrive
• wp-config-hærdning: saltnøgler, file edit og debug
• Alle undersider giver 404 i WordPress
• WordPress hosting hos Hostious – hosting der er sat op til WordPress fra starten

Ofte stillede spørgsmål om WordPress filrettigheder

Skal uploads-mappen have andre rettigheder end resten?

Nej. 755 på mapper og 644 på filer er nok, så længe filerne ejes af den bruger, PHP kører som. Kræver et plugin 777 for at virke, er det ejerskabet, der er forkert – ikke rettighederne.

Hvad med .htaccess?

644. Er den strammere, kan WordPress ikke opdatere permalink-reglerne, og undersider kan begynde at give 404.

Hvorfor skal wp-config.php være strammere end andre filer?

Fordi den indeholder databasens brugernavn og adgangskode. Med 640 eller 600 kan andre brugere på samme server ikke læse den, selv om de skulle få adgang til filsystemet.

Hvorfor beder WordPress om FTP-oplysninger, når jeg opdaterer?

Fordi WordPress har opdaget, at nye filer får en anden ejer end sitets egne filer, og derfor ikke tør skrive direkte. Ret ejerskabet, så filerne ejes af den bruger, PHP kører som – så forsvinder spørgsmålet.