“Could not create directory” — når WordPress ikke må skrive

Kort svar: “Installation failed: Could not create directory” betyder, at WordPress ikke har lov til at oprette mapper i wp-content. Det er et filsystemproblem, ikke en fejl i pluginnet. Den hyppigste årsag er, at filerne ejes af en anden bruger end den, PHP kører som – typisk efter en flytning eller gendannelse. Tjek skrivbarheden under Webstedets helbred, sæt 755/644, og få ejerskabet rettet. Sæt aldrig 777.

Fagligt gennemgået: 2. oktober 2026

Når WordPress ikke kan installere et plugin, et tema eller en opdatering, er “Could not create directory” den mest almindelige besked. Fejlen dukker typisk op efter en flytning eller en gendannelse fra backup, hvor filerne har fået en anden ejer end den, webserveren kører som.

Webserveren kører som én brugerkonto. Filerne ejes af en anden. Så længe de to ikke passer sammen, kan WordPress læse, men ikke skrive. Derfor rammer fejlen ofte alt på én gang: plugins, temaer, opdateringer og upload af billeder.

Før du ændrer noget: Tag en backup af filer og database. Ændr ikke rettigheder rekursivt på hele kontoen – kun på WordPress-installationen. Notér de nuværende rettigheder og ejere, så du kan rulle tilbage, og sæt aldrig 777 “for at teste”.

Symptom	Sandsynlig årsag	Første kontrol
Fejlen kom lige efter flytning eller gendannelse	Forkert ejer på filerne	Webstedets helbred → Filsystemrettigheder
WordPress beder om FTP-oplysninger	WordPress kan ikke skrive direkte	Ejerskab og FS_METHOD
Billeder kan uploades, men plugins ikke	Forskellige rettigheder på uploads og plugins	Rettigheder på wp-content/plugins
Fejlen kom pludselig uden ændringer	Fuld disk eller opbrugt antal filer (inodes)	Diskforbrug i kontrolpanelet
“Destination folder already exists”	Rester fra et afbrudt forsøg	Mappen i wp-content/plugins

1. Bekræft, at det er skriveadgangen

Gå til Værktøjer → Webstedets helbred → Info, og fold “Filsystemrettigheder” ud. Står der “Ikke skrivbar” ud for wp-content, plugins, temaer eller uploads, har du bekræftet problemet uden at røre serveren.

Har du SSH, kan du se det mere præcist:

ls -la wp-content
ps aux | grep -E 'php-fpm|lsphp'

ls -la viser, hvem der ejer mapperne, og ps aux viser, hvilken bruger PHP-processerne kører som. Er de to navne forskellige, er det ejerskabet – og så hjælper ingen rettigheder i verden. Bemærk, at WP-CLI kører som din SSH-bruger, så et vellykket wp plugin install beviser ikke, at webserveren også kan skrive.

2. Sæt de rigtige rettigheder

Standarden i WordPress er 755 på mapper og 644 på filer. wp-config.php kan med fordel være strammere (fx 640 eller 600), hvis serveren tillader det. I kontrolpanelets filhåndtering kan rettighederne sættes rekursivt; med SSH ser det sådan ud, kørt fra sitets rodmappe:

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

Se hvad 644 og 755 betyder, hvis du vil forstå tallene.

3. Ret ejerskabet

Rettigheder hjælper ikke, hvis ejeren er forkert. Det er den hyppigste egentlige årsag. Har du selv root-adgang til serveren, retter du det med én kommando, hvor web erstattes af den bruger og gruppe, PHP kører som:

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

På delt hosting har du ikke den adgang, og det er meningen – så er det supporten, der skal gøre det. Er sitet hostet hos Hostious, kan supporten tjekke og rette ejerskabet døgnet rundt.

4. Tjek de andre årsager med samme fejlbesked

• Disken er fuld. WordPress kan ikke oprette en mappe, hvis der ikke er plads. Tjek diskforbruget i kontrolpanelet – gamle backups, logfiler og cache er de typiske syndere.
• Grænsen for antal filer (inodes) er nået. Nogle konti har både en pladsgrænse og en grænse for antal filer. Mange små cachefiler kan ramme den, selv om der er plads tilbage.
• FS_METHOD står forkert. Ligger der en linje med define( 'FS_METHOD', 'ftpext' ); i wp-config.php fra en gammel server, forsøger WordPress at skrive via FTP og fejler. Skift den til 'direct', eller fjern linjen.
• Den midlertidige mappe virker ikke. WordPress henter og pakker pakker ud i en midlertidig mappe først. Er PHP’s tmp-mappe ikke skrivbar, kan du pege på en mappe i wp-content med define( 'WP_TEMP_DIR', __DIR__ . '/wp-content/temp/' ); og oprette mappen.
• open_basedir-begrænsning. Er PHP låst til bestemte mapper, og peger en sti fra den gamle server uden for dem, nægtes skrivning. Fejlloggen nævner så “open_basedir restriction in effect”.

Hvorfor du ikke skal sætte 777

777 betyder, at alle brugere på serveren må skrive i mappen. Det kan få fejlen til at forsvinde – og åbner samtidig for, at et andet kompromitteret site på samme server kan lægge filer ind hos dig.

Mange servere, der kører PHP som kontoens egen bruger, afviser desuden at køre filer med for åbne rettigheder af netop den grund, så du kan ende med en 500-fejl oveni. Se guiden til sikker hjemmesidehosting.

Omvejen, hvis du skal videre nu

Skal pluginnet ind i dag, og kan ejerskabet først rettes i morgen, så upload det manuelt: hent zip-filen fra WordPress.org eller leverandøren, pak den ud, og læg mappen i wp-content/plugins via SFTP eller kontrolpanelets filhåndtering. Aktivér det derefter under Plugins.

Det virker, fordi det er dig og ikke webserveren, der opretter mappen – men filerne kan så også få en anden ejer, og pluginnet kan ikke opdatere sig selv senere. Se det som en nødløsning, ikke som en vane.

Fejl, der ligner – men har en anden årsag

• “Destination folder already exists” betyder, at mappen allerede ligger der fra et tidligere forsøg, som blev afbrudt. Slet den halve mappe, og installér igen. Se “Destination folder already exists”.
• “Unable to create directory uploads/…” kommer, når upload-mappen er beskyttet eller peger på en sti fra den gamle server. Tjek feltet upload_path i databasen eller under Indstillinger → Medier, hvis det vises – det skal normalt være tomt.
• “PCLZIP_ERR_MISSING_FILE” er en zip-fil, der ikke kunne pakkes ud i den midlertidige mappe – ofte samme rettighedsproblem i forklædning, eller en ufuldstændig download.

Verificér, at filsystemet er i orden

Efter en flytning er det en god vane at teste netop dette, før du melder sitet klar:

1. Upload et billede i mediebiblioteket.
2. Installér og slet et lille plugin.
3. Kør en plugin- eller temaopdatering.
4. Tjek, at Webstedets helbred viser alle mapper som skrivbare.

Virker de fire ting, er filsystemet i orden. Ved en gratis migrering hos Hostious kan du bede supporten tjekke netop disse punkter, så fejlen ikke først dukker op, når du selv skal opdatere.

Læs også

• Hub: WordPress fejl og fejlfinding
• Filrettigheder i WordPress – hvad 644 og 755 betyder
• “Destination folder already exists”
• HTTP-fejl ved upload af billeder
• WordPress hosting hos Hostious – daglig backup, staging fra WP StartUp og dansk support 24/7

Ofte stillede spørgsmål om “Could not create directory”

Hvorfor virker upload af billeder, men ikke plugins?

Fordi uploads-mappen kan have andre rettigheder eller en anden ejer end resten af wp-content. Tjek begge under Webstedets helbred.

Skal jeg bruge FTP-oplysninger, når WordPress spørger?

Det er en nødløsning, når WordPress ikke kan skrive direkte. Bedre er at rette ejerskabet, så WordPress kan skrive selv, og så forsvinder spørgsmålet.

Hvordan ser jeg, om filerne har den forkerte ejer, uden SSH?

Under Værktøjer → Webstedets helbred → Info → Filsystemrettigheder viser WordPress, om wp-content, plugins, temaer og uploads er skrivbare. Er de ikke skrivbare, selv om rettighederne er 755, er det ejerskabet.

Kan en fuld disk give samme fejl?

Ja. Når der ikke er plads, eller grænsen for antal filer er nået, kan der ikke oprettes mapper, og fejlbeskeden er den samme. Tjek diskforbruget i kontrolpanelet, og ryd op i gamle backups, logfiler og cache.