„Sorry, you are not allowed to access this page“ efter flytning

Kort svar: Beskeden betyder, at du er logget korrekt ind – men din bruger har ingen rettigheder til siden. Efter en flytning er årsagen næsten altid et præfiks-mismatch: wp-config.php og tabellerne bruger ét præfiks, mens rettighedsnøglerne inde i databasen stadig står med et andet. Sammenlign $table_prefix, tabelnavnene og nøglerne, og bring dem på linje – typisk ved at omdøbe nøglerne.

Fagligt gennemgået: 2. oktober 2026

Flytningen gik tilsyneladende fint: forsiden virker, du kan logge ind – og så møder wp-admin dig med „Sorry, you are not allowed to access this page“ (på dansk: „Beklager, du har ikke adgang til denne side“). Det føles som en låst dør, men beskeden handler om rettigheder, ikke om login, og efter en migrering peger den næsten altid samme sted hen.

Guiden går fra den hyppigste årsag – tabelpræfikset – til de sjældnere: ødelagte rolledefinitioner, store og små bogstaver, multisite og plugins, der begrænser adgangen.

Før du ændrer noget: Tag en backup af databasen og en kopi af wp-config.php. Ret kun ét sted ad gangen – enten wp-config eller databasen – og test wp-admin efter hver ændring.

Ikke det samme som 403

En 403 Forbidden kommer fra serveren eller en firewall, før WordPress overhovedet svarer. „Sorry, you are not allowed“ kommer derimod fra WordPress selv: requesten nåede frem, du er logget ind, men WordPress kan ikke finde en rolle på din bruger, der giver adgang. Det skel afgør, hvor du skal lede – her handler det om databasen og WordPress’ rettighedssystem, ikke om serveren.

Kan du slet ikke logge ind, er det et andet problem. Se i stedet guiden om at være låst ude af wp-admin.

Sådan gemmer WordPress rettigheder

For at forstå fejlen hjælper det at vide, hvor rettighederne ligger. WordPress bruger tre nøgler, som alle indeholder tabelpræfikset:

Nøgle	Tabel	Indhold
PRÆFIKS_capabilities	usermeta	Hvilke roller den enkelte bruger har, fx administrator
PRÆFIKS_user_level	usermeta	Ældre talværdi for brugerniveau, som stadig gemmes
PRÆFIKS_user_roles	options	Definitionen af alle roller og deres rettigheder

Står præfikset forkert i en af dem, kan WordPress ikke koble din bruger til en rolle – og uden rolle har du ingen adgang til admin-siderne.

1. Sammenlign tabelpræfikset

Skifter præfikset under en flytning – fordi tabellerne blev omdøbt, eller fordi databasen kommer fra en anden installation – leder WordPress efter wpnyt_capabilities, mens databasen indeholder wpgml_capabilities. Resultatet: du findes som bruger, men uden rettigheder.

Sammenlign derfor to ting: $table_prefix i wp-config.php og de faktiske tabelnavne i databasen (phpMyAdmin viser dem i venstre kolonne). Med WP-CLI kan du se begge dele på få sekunder:

wp config get table_prefix
wp db tables --all-tables
wp db query "SELECT meta_key FROM wpnyt_usermeta WHERE meta_key LIKE '%capabilities'"

Den sidste kommando viser, hvilke præfikser der faktisk står foran capabilities i usermeta. Skift wpnyt_usermeta ud med dit eget tabelnavn.

2. Vælg den rigtige løsning

Der er to scenarier, og de kræver hver sin løsning:

• Tabellerne har nyt præfiks, men meta-nøglerne har det gamle: det er det klassiske billede bag beskeden og sker ved halve præfiks-omdøbninger, hvor kun tabelnavnene blev ændret. Nøglerne i databasen skal opdateres, så de matcher tabellerne og wp-config.php.
• wp-config.php peger på et helt andet præfiks end tabellerne: så finder WordPress normalt slet ingen tabeller og viser installationssiden – eller en tom, frisk installation, hvis begge sæt tabeller ligger i samme database. Ret $table_prefix til det præfiks, dine rigtige tabeller har. Én linje, ingen dataændringer.

For det andet scenarie ser linjen i wp-config.php sådan ud, når dine tabeller hedder wpgml_posts, wpgml_users og så videre:

$table_prefix = 'wpgml_';

For det første scenarie omdøber du nøglerne i SQL. Eksemplet går fra det gamle præfiks wpgml_ til det nye wpnyt_ – tilpas begge, og tag en databasebackup først:

UPDATE wpnyt_options
SET option_name = 'wpnyt_user_roles'
WHERE option_name = 'wpgml_user_roles';

UPDATE wpnyt_usermeta
SET meta_key = CONCAT('wpnyt_', SUBSTRING(meta_key, 7))
WHERE meta_key LIKE 'wpgml\_%';

Tallet 7 er længden af det gamle præfiks plus én (wpgml_ har seks tegn). Den anden forespørgsel retter både capabilities, user_level og andre brugerindstillinger, som WordPress gemmer med præfiks.

Bland aldrig de to veje sammen: vælg én kilde til sandheden – enten følger wp-config databasen, eller databasen bringes på linje med wp-config – og gennemfør den hele vejen.

3. Tjek store og små bogstaver

På Linux-servere skelner databasen normalt mellem store og små bogstaver i tabelnavne, mens en lokal udviklingsmaskine på Windows ofte gemmer tabelnavne med små bogstaver. Havde det oprindelige site et præfiks med store bogstaver, fx WP_, kan tabellerne derfor ende som wp_posts, mens nøglerne inde i tabellerne stadig hedder WP_capabilities og WP_user_roles.

WordPress slår nøglerne op i PHP, hvor WP_capabilities og wp_capabilities er to forskellige nøgler. Løsningen er den samme som ved et præfiks-skift: omdøb nøglerne, så de står præcis som præfikset i wp-config.php og tabelnavnene.

4. Gendan rolledefinitionerne

Matcher præfikset, men har brugeren stadig ingen adgang, kan selve rolledefinitionen i PRÆFIKS_user_roles være tom eller ødelagt – fx efter en mislykket søg-og-erstat i databasen, der har brudt den serialiserede værdi. Så findes rollen „administrator“ ikke længere, selvom brugeren står med den.

Med WP-CLI kan du tjekke og gendanne standardrollerne og give din bruger administratorrollen igen:

wp role list
wp role reset --all
wp user list --fields=ID,user_login,roles
wp user set-role DIT_BRUGERNAVN administrator

Bemærk, at wp role reset sætter standardrollerne tilbage til WordPress’ udgangspunkt. Har et plugin tilføjet ekstra rettigheder til fx redaktører eller butiksansvarlige, skal de sættes op igen bagefter – typisk ved at gemme pluginets indstillinger eller genaktivere det.

Søg-og-erstat i en WordPress-database bør altid ske med et værktøj, der forstår serialiserede data, som wp search-replace. En almindelig tekst-erstatning i en SQL-fil kan ødelægge længdeangivelserne i serialiserede værdier – og rolledefinitionen er en af dem.

5. Andre årsager

Er præfiks og roller i orden, så gå disse muligheder igennem i rækkefølge:

• Rollen er reelt ændret: din bruger kan være fjernet eller nedgraderet. En anden administrator kan bekræfte det under Brugere.
• Multisite: er sitet flyttet ud af et multisite-netværk, lå superadmin-rettighederne på netværksniveau og fulgte ikke med. Brugeren skal have en almindelig administratorrolle på det enkelte site.
• En gammel plugin-side: beskeden kommer også, hvis du åbner et bogmærke som admin.php?page=… til et plugin, der er deaktiveret eller ikke er flyttet med. Siden findes simpelthen ikke længere.
• Sikkerhedsplugins: enkelte sikkerheds- og rolleplugins begrænser adgangen til udvalgte admin-sider. Deaktivér dem kortvarigt via konflikttest-metoden, hvis beskeden kun rammer bestemte sider.
• Konstanter i wp-config.php: DISALLOW_FILE_EDIT og DISALLOW_FILE_MODS fjerner bevidst adgangen til fil-editoren og til installation af plugins og temaer. Det giver lignende afvisninger på netop de sider – og er normalt tilsigtet.

6. Bekræft, at sagen er lukket

Sagen er lukket, når:

• du kan åbne alle admin-sider, også Indstillinger og Plugins;
• din bruger står som administrator under Brugere;
• et gem af permalinks går igennem uden fejl;
• de øvrige brugere har de roller, de skal have.

Det sidste punkt er vigtigt: en præfiks-fejl rammer alle brugere på én gang, så kollegernes og eventuelle kunders roller skal også være på plads. Flytter du til Hostious, er den slags tjek en del af den gratis migrering – så opdages præfiks-problemer, før du gør.

Undgå fejlen ved næste flytning

1. Notér $table_prefix fra det gamle site, før du flytter.
2. Eksportér hele databasen samlet, og importér den uden at omdøbe tabeller undervejs.
3. Brug wp search-replace til at skifte domæne – aldrig en ren tekst-erstatning i SQL-filen.
4. Test wp-admin som det første efter flytningen, før DNS peges om.

Den fulde fremgangsmåde står i guiden om at flytte en WordPress-hjemmeside til ny hosting.

Læs også

• Hub: WordPress fejl og fejlfinding
• 403 Forbidden i WordPress: rettigheder, firewall eller plugin?
• Låst ude af wp-admin — sådan kommer du ind igen
• Efter flytningen: tjeklisten, der fanger alt det glemte
• Gratis migrering til Hostious – vi flytter dit WordPress-site og tester det, før domænet peges om

Ofte stillede spørgsmål om beskeden

Hvorfor virker forsiden, når wp-admin er lukket?

Fordi forsiden ikke kræver rettigheder. WordPress finder fint indholdet i databasen – det er kun koblingen mellem din bruger og en rolle, der er knækket.

Er mine data væk?

Nej. Indlæg, sider, ordrer og brugere ligger urørt i databasen. Fejlen sidder i én konfigurationslinje eller nogle få meta-nøgler – og begge dele kan rettes uden tab.

Kan jeg oprette en ny administrator i stedet?

Det løser sjældent problemet. Ligger rolledefinitionen stadig under det gamle præfiks, findes rollen „administrator“ ikke for WordPress, og den nye bruger får samme fejl. Ret præfikset på nøglerne først – så virker de eksisterende brugere igen.

Kan jeg forebygge det ved næste flytning?

Ja: flyt altid wp-config.php’s $table_prefix sammen med databasen, og test wp-admin som det første efter flytningen. Eller lad hostingudbyderen stå for flytningen – så er præfiks-tjekket deres ansvar.