Flyttet du nettstedet til hosting, og pluginene sluttet å installere seg? Eller medieopplastinger via administrasjonspanelet feiler? Eller en kjerneoppdatering feiler med «Could not create directory.» Høres det kjent ut?

Årsaken er nesten alltid den samme: feil fil- og mappetillatelser. En lokal server (OpenServer, MAMP) kjører under den gjeldende Windows/macOS-brukeren og tilgir alt. En produksjonshosting med Linux gjør ikke det. Hver fil og mappe har en eier og tre tillatelsesnivåer, og hvis webserveren ikke kan skrive til den nødvendige mappen, bryter nettstedet sammen i stillhet eller med en kryptisk feilmelding.

Nedenfor finner du hva 755 og 644 faktisk betyr, hvordan du setter dem én gang via FileZilla for hele nettstedet, og hvilke filer som krever spesiell håndtering.

💡 Rask oversikt:

• Hva tallene 755 og 644 betyr og hvorfor 777 er et sikkerhetshull
• Hvordan du massesett tillatelser via FileZilla i 2 omganger: først mapper, så filer
• Hvilke tillatelser wp-config.php, .htaccess og wp-content-mappen trenger
• Hvordan du gjør det samme via SSH med én kommando på 5 sekunder

Hva tillatelser betyr og hvorfor 777 er en katastrofe

Hver fil og mappe på en Linux-server lagrer tre tillatelsessett: for eieren, for gruppen og for alle andre. Tallet er en sum av bits: 4 (lese) + 2 (skrive) + 1 (kjøre, som for mapper betyr å gå inn i dem).

755 for mapper brytes ned slik: eieren kan gjøre alt (7), gruppen og andre kan lese og gå inn (5). Mappen er tilgjengelig for webserveren for å skanne og opprette filer og undermapper inni, men ingen utenforstående kan slette eller gi den nytt navn.

644 for filer: eieren kan lese og skrive (6), andre kan bare lese (4). PHP-filer kjøres av tolken, ikke systemet, så de trenger ikke kjørebiten.

777 (eier+gruppe+andre = alt) er en åpen dør. Enhver prosess på serveren, inkludert skript fra nabonettsteder på delt hosting, kan lese, endre og slette filene dine. Ifølge WPScans data for 2025 er feil tillatelser blant de fem vanligste angrepsvektorene for WordPress på delt hosting. Sett aldri 777. Hvis en plugin eller et tema krever slike tillatelser, er det et faresignal.

Hvilke tillatelser WordPress anser som korrekte

Den offisielle WordPress-dokumentasjonen definerer anbefalte tillatelser som følger:

På de fleste hoster samsvarer filsystemeieren med brukeren PHP kjører som (suPHP/FastCGI + suEXEC-konfigurasjon). I dette oppsettet er 755/644-tillatelser tilstrekkelige: WordPress kan skrive til wp-content/uploads, oppdatere kjernen og plugins, og installere temaer uten å eskalere til 777.

Sjekk om dette gjelder for din host: gå til administrasjonspanelet og prøv å installere en hvilken som helst gratis plugin. Hvis den installeres uten å be om FTP-legitimasjon, fungerer 755/644-oppsettet og tillatelsene er allerede korrekte.

Hvordan sette tillatelser via FileZilla: trinn for trinn

FileZilla er en gratis FTP-klient som kan masseendre tillatelser rekursivt. Last den ned fra det offisielle nettstedet hvis du ikke allerede har gjort det.

Trinn 1: koble til og naviger til WordPress-roten

Koble til hostingen din via FTP (brukernavn/passord er det samme som for hostingkontoen din, port 21). I høyre panel navigerer du til nettstedets rotmappe, der wp-config.php, wp-content, wp-admin og wp-includes ligger.

Trinn 2: sett 755 på alle mapper

Velg alle filer og mapper i roten (Ctrl+A). Høyreklikk → «Filtillatelser».

I dialogboksen som åpnes, skriv inn 755 i feltet «Numerisk verdi». Kryss av for «Rekursivt i undermapper». Sett radioknappen til «Bruk kun på mapper». Klikk OK.

FileZilla vil gå gjennom hver mappe og undermappe på nettstedet og sette 755. Prosessen tar fra noen sekunder til et par minutter avhengig av nettstedets størrelse.

Trinn 3: sett 644 på alle filer

Velg alt i roten igjen (Ctrl+A), høyreklikk igjen → «Filtillatelser».

Skriv nå inn 644. Kryss av for «Rekursivt i undermapper». Sett radioknappen til «Bruk kun på filer». OK.

Ferdig. To omganger (mapper og filer) og hele nettstedet er brakt til standard.

Rask metode via SSH: find-kommandoen

Hvis du har SSH-tilgang til serveren, tar den samme operasjonen to kommandoer og fem sekunder:

1
find /path/to/wordpress -type d -exec chmod 755 {} \;
2
find /path/to/wordpress -type f -exec chmod 644 {} \;

Den første går gjennom alle mapper (-type d) og setter 755. Den andre går gjennom alle filer (-type f) og setter 644. Erstatt /path/to/wordpress med den faktiske banen til nettstedets rot (vanligvis /home/username/public_html).

Etter det strammer du inn wp-config.php separat:

1
chmod 600 /path/to/wordpress/wp-config.php

Og .htaccess, hvis du har en (Apache-server):

1
chmod 644 /path/to/wordpress/.htaccess

Hvis nettstedet ditt kjører på Nginx, finnes det ingen .htaccess-fil, så hopp over dette trinnet.

Hva du gjør hvis tillatelser tilbakestilles

Situasjon: du satte 755/644, alt fungerte, og en uke senere får du den samme feilen. Årsaken er vanligvis en prosess som kjører under en annen bruker.

Typiske syndere:

• Cron-jobber fra hosten. Noen hoster kjører vedlikeholdsskripter som root, og de oppretter filer med tillatelser webserveren ikke kan overskrive etterpå. Løsning: be support om å konfigurere cron til å kjøre under din bruker.
• Tredjeparts backup-plugin. Skriver dumps og arkiver til wp-content under den brukeren den nå kjører som. Sjekk pluginens logger. Hvis den oppretter filer under en annen bruker enn nettstedets eier, bytt til et alternativ.
• Caching-plugin. Oppretter cache-mapper med feil tillatelser. Gå til pluginens innstillinger og finn knappen «Tøm cache» eller «Tilbakestill tillatelser».

Universell hurtigfiks: gjenta prosedyren fra avsnittet over (FileZilla i 2 omganger eller to find-kommandoer). Dette løser ikke rotårsaken, men vil gjenopprette nettstedet til fungerende stand.

⁉️🤔 Ofte stilte spørsmål

Hva om nettstedet krasjer til en «hvit dødsskjerm» etter endring av tillatelser?

En hvit skjerm (WSOD) etter masseendring av tillatelser er ekstremt sjeldent, men mulig. Først: aktiver WP_DEBUG i wp-config.php slik at du ser feilteksten i stedet for en hvit skjerm. Andre: sjekk om du ved et uhell satte 644 på mapper (mapper trenger kjørebiten, som betyr 5 på slutten). Fiks det med én find-kommando: find /path -type d -exec chmod 755 {} \;. Dette er nok i de fleste tilfeller. Hvis nettstedet fortsatt ikke fungerer, gjenopprett fra backup og endre tillatelser gradvis: først på wp-content, så på roten, mens du observerer reaksjoner.

Kan jeg sette tillatelser gjennom hostingens innebygde filbehandler?

Ja, men bare for enkeltfiler og mapper. cPanel-hoster tilbyr en Filbehandler med «Endre tillatelser» i kontekstmenyen. Å rekursivt sette tillatelser på hundrevis eller tusenvis av filer via et webgrensesnitt er imidlertid praktisk talt umulig. For masseoperasjoner, bruk FileZilla eller SSH.

Hvilke tillatelser bør wp-content/uploads-mappen ha?

Standard 755, som alle andre mapper. Hvis en plugin eller et tema oppretter undermapper i uploads og har problemer, sjekk prosesseieren (bør samsvare med mappeeieren) i stedet for å heve tillatelsene til 777. Noen ganger løses problemet ved å legge til define('FS_METHOD', 'direct'); i wp-config.php.

Må jeg sette tillatelser på filer i wp-admin og wp-includes?

Ja, standard 644 for filer og 755 for mapper, samme som resten av nettstedet. FileZilla-prosedyren (velge alt i roten) håndterer dem automatisk.

Min host krever 777 på noen mapper. Er dette normalt?

Nei. Å kreve 777 er et tegn på at PHP på serveren kjører under en annen bruker enn fileieren (for eksempel mod_php uten suEXEC). I denne konfigurasjonen kan ikke WordPress skrive til mapper uten «world»-tilgang. Alternativer: bytt til en host som bruker suPHP/FastCGI (de fleste moderne gjør det), eller legg til define('FS_METHOD', 'direct'); i wp-config.php, noe som noen ganger er nok.

Korrekte tillatelser er et fundament, ikke et alternativ

Å sette 755 på mapper og 644 på filer lukker den vanligste kanalen for «mystiske» feil når du migrerer et nettsted. To minutter i FileZilla eller to SSH-kommandoer sparer timer med gjetting over logger.

Hvis nettstedet ditt ligger på en god hosting med suPHP/FastCGI, er disse tillatelsene nok til alt: installere plugins, laste opp mediefiler og automatiske kjerneoppdateringer. Ikke hev tillatelsene til 777, selv om en gammel plugins instruksjoner ber om det. Og legg til wp-config.php som et eget punkt: chmod 600. Den inneholder databasepassordet, og utenforstående trenger ikke tilgang til det.