Flyttade du din webbplats till ett webbhotell och plugins slutade installeras? Eller går det inte att ladda upp mediafiler via adminpanelen? Eller misslyckas en kärnuppdatering med "Could not create directory."? Låter det bekant?

Orsaken är nästan alltid densamma: felaktiga fil- och mapprättigheter. En lokal server (OpenServer, MAMP) körs under den aktuella Windows-/macOS-användaren och förlåter allt. Ett produktionsbaserat Linux-webbhotell gör det inte. Varje fil och mapp har en ägare och tre rättighetsnivåer, och om webbservern inte kan skriva till den nödvändiga mappen går webbplatsen sönder under tystnad eller med ett kryptiskt felmeddelande.

Här nedan får du veta vad 755 och 644 faktiskt betyder, hur du ställer in dem en gång via FileZilla för hela webbplatsen och vilka filer som kräver särskild hantering.

💡 Snabb översikt:

• Vad siffrorna 755 och 644 betyder och varför 777 är ett säkerhetshål
• Hur du massändrar rättigheter via FileZilla i två steg: först mappar, sedan filer
• Vilka rättigheter wp-config.php, .htaccess och mappen wp-content behöver
• Hur du gör samma sak via SSH med ett enda kommando på fem sekunder

Vad rättigheterna betyder och varför 777 är en katastrof

Varje fil och mapp på en Linux-server lagrar tre rättighetsuppsättningar: för ägaren, för gruppen och för alla andra. Siffran är en summa av bitar: 4 (läs), 2 (skriv) och 1 (exekvera, vilket för mappar betyder att man kan gå in i dem).

755 för mappar bryts ner så här: ägaren kan göra allt (7), gruppen och andra kan läsa och gå in (5). Mappen är tillgänglig för webbservern för att skanna och skapa filer och undermappar inuti, men ingen utomstående kan ta bort eller byta namn på den.

644 för filer: ägaren kan läsa och skriva (6), andra kan bara läsa (4). PHP-filer körs av tolken, inte av systemet, så de behöver inte exekveringsbiten.

777 (ägare+grupp+andra = allt) är en öppen dörr. Alla processer på servern, inklusive skript från grannwebbplatser på delade webbhotell, kan läsa, ändra och ta bort dina filer. Enligt WPScans data för 2025 är felaktiga rättigheter bland de fem vanligaste WordPress-attackvektorerna på delade webbhotell. Sätt aldrig 777. Om ett plugin eller tema kräver sådana rättigheter är det en varningsflagga.

Vilka rättigheter WordPress anser vara korrekta

Den officiella WordPress-dokumentationen definierar rekommenderade rättigheter enligt följande:

På de flesta webbhotell matchar filsystemets ägare den användare som PHP körs som (suPHP/FastCGI + suEXEC-konfiguration). I denna uppsättning är 755/644-rättigheter tillräckliga: WordPress kan skriva till wp-content/uploads, uppdatera kärnan och plugins samt installera teman utan att eskalera till 777.

Kontrollera om detta gäller för ditt webbhotell: gå till adminpanelen och försök installera ett gratis plugin. Om det installeras utan att fråga efter FTP-uppgifter fungerar 755/644-upplägget och rättigheterna är redan korrekta.

Så ställer du in rättigheter via FileZilla: steg för steg

FileZilla är en gratis FTP-klient som kan massändra rättigheter rekursivt. Ladda ner den från den officiella webbplatsen om du inte redan har den.

Steg 1: anslut och navigera till WordPress rot

Anslut till ditt webbhotell via FTP (inloggning/lösenord är samma som för ditt webbhotellskonto, port 21). I den högra panelen navigerar du till webbplatsens rotmapp, där wp-config.php, wp-content, wp-admin och wp-includes finns.

Steg 2: sätt 755 på alla mappar

Markera alla filer och mappar i roten (Ctrl+A). Högerklicka → "Filrättigheter".

I dialogrutan som öppnas anger du 755 i fältet "Numeriskt värde". Markera kryssrutan "Gå igenom undermappar". Ställ radioknappen på "Tillämpa endast på mappar". Klicka på OK.

FileZilla går igenom varje mapp och undermapp på webbplatsen och sätter 755. Processen tar från några sekunder till ett par minuter beroende på webbplatsens storlek.

Steg 3: sätt 644 på alla filer

Markera allt i roten igen (Ctrl+A), högerklicka igen → "Filrättigheter".

Ange nu 644. Markera "Gå igenom undermappar". Ställ radioknappen på "Tillämpa endast på filer". OK.

Klart. Två genomgångar (mappar och filer) och hela webbplatsen är återställd till standard.

Snabbmetod via SSH: find-kommandot

Om du har SSH-åtkomst till servern tar samma operation två kommandon och fem sekunder:

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

Det första går igenom alla mappar (-type d) och sätter 755. Det andra går igenom alla filer (-type f) och sätter 644. Ersätt /path/to/wordpress med den faktiska sökvägen till din webbplatsrot (vanligtvis /home/username/public_html).

Därefter skärper du separat wp-config.php:

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

Och .htaccess, om du har en sådan (Apache-server):

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

Om din webbplats körs på Nginx finns det ingen .htaccess-fil, så hoppa över detta steg.

Vad du ska göra om rättigheterna återställs

Situation: du satte 755/644, allt fungerade, och en vecka senare får du samma fel. Orsaken är vanligtvis en process som körs under en annan användare.

Typiska bovar:

• Cron-jobb från webbhotellet. Vissa webbhotell kör underhållsskript som root, och de skapar filer med rättigheter som webbservern inte kan skriva över efteråt. Lösning: be supporten konfigurera cron att köras under din användare.
• Tredjeparts backup-plugin. Skriver dumpar och arkiv till wp-content under den användare det körs som. Kontrollera plugin-loggarna. Om det skapar filer under en annan användare än webbplatsägaren, byt till ett alternativ.
• Caching-plugin. Skapar cache-mappar med felaktiga rättigheter. Gå till plugin-inställningarna och leta efter en "Rensa cache" eller "Återställ rättigheter"-knapp.

Universell snabbfix: upprepa proceduren från avsnittet ovan (FileZilla i två steg eller två find-kommandon). Detta löser inte grundorsaken men återställer webbplatsen till fungerande skick.

⁉️🤔 Vanliga frågor

Vad händer om webbplatsen kraschar till en "vit dödsskärm" efter att jag ändrat rättigheterna?

En vit skärm (WSOD) efter massändring av rättigheter är extremt ovanligt men möjligt. Först: aktivera WP_DEBUG i wp-config.php så att du ser feltexten istället för en vit skärm. Andra: kontrollera om du av misstag satte 644 på mappar (mappar behöver exekveringsbiten, vilket innebär en 5:a på slutet). Åtgärda det med ett find-kommando: find /path -type d -exec chmod 755 {} \;. Detta räcker i de flesta fall. Om webbplatsen fortfarande inte fungerar, återställ från säkerhetskopia och ändra rättigheterna gradvis: först på wp-content, sedan på roten, och observera reaktionerna.

Kan jag ställa in rättigheter via webbhotellets inbyggda filhanterare?

Ja, men bara för enskilda filer och mappar. cPanel-webbhotell har en filhanterare med "Ändra rättigheter" i snabbmenyn. Att rekursivt ställa in rättigheter på hundratals eller tusentals filer via ett webbgränssnitt är dock praktiskt taget omöjligt. För massoperationer, använd FileZilla eller SSH.

Vilka rättigheter ska mappen wp-content/uploads ha?

Standard 755, som alla andra mappar. Om ett plugin eller tema skapar undermappar inuti uploads och får problem, kontrollera processägaren (bör matcha mappägaren) istället för att höja rättigheterna till 777. Ibland löses problemet genom att lägga till define('FS_METHOD', 'direct'); i wp-config.php.

Behöver jag ställa in rättigheter på filer inuti wp-admin och wp-includes?

Ja, standard 644 för filer och 755 för mappar, samma som för resten av webbplatsen. FileZilla-proceduren (att markera allt i roten) hanterar dem automatiskt.

Mitt webbhotell kräver 777 på vissa mappar. Är detta normalt?

Nej. Att kräva 777 är ett tecken på att PHP på servern körs under en annan användare än filägaren (till exempel mod_php utan suEXEC). I denna konfiguration kan WordPress inte skriva till mappar utan "världs"-åtkomst. Alternativ: byt till ett webbhotell som använder suPHP/FastCGI (de flesta moderna gör det), eller lägg till define('FS_METHOD', 'direct'); i wp-config.php, vilket ibland räcker.

Korrekta rättigheter är en grundförutsättning, inte ett tillval

Att sätta 755 på mappar och 644 på filer stänger den vanligaste kanalen för "mystiska" fel vid migrering av en webbplats. Två minuter i FileZilla eller två SSH-kommandon sparar timmar av gissande över loggar.

Om din webbplats ligger på ett bra webbhotell med suPHP/FastCGI räcker dessa rättigheter för allt: installera plugins, ladda upp media och automatiska kärnuppdateringar. Höj inte rättigheterna till 777, även om ett gammalt plugins instruktioner ber om det. Och lägg till wp-config.php som en separat punkt: chmod 600. Den innehåller databaslösenordet, och utomstående behöver inte åtkomst till den.