Fixing the Not Allowed to Access This Page Error
WordPress checked a capability and the account did not have it. After a migration the usual reason is not the role at all — it is that the table prefix changed and the row describing the account's role no longer matches.
WordPress asked whether this account may do this thing and the answer was no. That is all the message says. The account may genuinely lack the role, or it may hold a role WordPress cannot find because the rows describing it are named after a table prefix that changed. The second case is the one that strands people after a migration, and it is invisible from the dashboard because the dashboard is what it blocks.
The table prefix trap
A user's role is stored in the user meta table under keys built from the database prefix. On a standard install those keys begin wp_. On an install using a custom prefix they begin with that instead.
Move a database into an install configured with a different prefix and the tables are found — the prefix in the configuration file matches them — but the meta keys inside still carry the old name. WordPress looks for a key matching the current prefix, finds nothing, and concludes the account has no role.
The tell is unmistakable: login succeeds, and every admin screen refuses. If login failed, this is not the cause.
The repair is to rename the two keys to match the current prefix. Working directly in the database is covered in adding a WordPress admin user via phpMyAdmin, and the same access is what makes this fixable:
UPDATE wp_usermeta SET meta_key = 'newprefix_capabilities'
WHERE meta_key = 'oldprefix_capabilities';
UPDATE wp_usermeta SET meta_key = 'newprefix_user_level'
WHERE meta_key = 'oldprefix_user_level';
Take a database backup before running either statement. A mistyped prefix here removes the role from every account at once, and the site has no administrator left to undo it with.
When it is genuinely the role
If the prefix is consistent, check what the account actually is. A user demoted to Subscriber can log in and reach the profile screen and nothing else, which produces this message on every other page.
Roles can also be altered by code. A plugin that adds custom roles, or a snippet that removed a capability, changes what the account may do without changing the label it displays. A role named Administrator whose capabilities were edited is the confusing version of this.
Plugins that restrict admin access deliberately
Several categories of plugin produce this message as designed behaviour:
- Security plugins restricting the dashboard by role, by address range, or outside a time window.
- Membership plugins filtering capabilities to control who reaches what.
- Multisite configurations, where a user existing on one site of the network has no role on another and sees this on that site only.
Narrowing it follows the usual route: deactivate plugins in groups until access returns, then reintroduce them, as in fixing plugin conflicts. Deactivating by renaming the plugin directory over SFTP works when the dashboard itself is unreachable.
The screen matters
The message also appears on a single screen while the rest of the dashboard works. That is a narrower fault:
| Where it appears | Likely cause |
|---|---|
| Everywhere | Role or prefix |
| One admin screen | That screen requires a capability the role lacks |
| The file editor only | DISALLOW_FILE_EDIT is set, working exactly as intended |
| After submitting a form | An expired or missing nonce rather than a role |
The last row catches people out. A form left open too long fails its security check on submission and produces the same wording, and reloading the page fixes it. The file editor row is the one to check before treating a deliberate hardening step as a bug — see DISALLOW_FILE_EDIT.
Recovering with no administrator at all
If no account can reach the dashboard, the route in is the database. Create a new user row and give it administrator capabilities under the correct prefix, then log in as that account and repair the original.
Do this on a copy first if the site is live and you are unsure of the prefix. A wrong guess adds broken rows rather than fixing existing ones, and the diagnosis gets harder each time.
Verify with more than one account
After the fix, log in as an administrator and open Users, Plugins, Appearance and Settings. Then log in as a lower-privileged account and confirm it is still correctly restricted — a prefix repair applied too broadly can promote every user on the site, which is a worse outcome than the lockout and much quieter.
If access is restored but the site misbehaves elsewhere, the migration that caused this probably left other addresses stale too, and the next stop is WP_HOME and WP_SITEURL.
Frequently asked
- Because the keys that store a user's role are named after the database table prefix. If the new install uses a different prefix, the old rows no longer match the name WordPress looks for, and the account resolves to no role at all.
- Access the database directly and correct the capability rows, or create a fresh administrator account there. Both are done outside the dashboard, which is the point — the dashboard is what you cannot reach.
- Yes. Security plugins restrict admin screens by role or by address, and a membership plugin can filter capabilities. If the role looks correct in the database, that is where to look next.