Fix “Sorry, You Are Not Allowed to Access This Page”

The WordPress “Sorry, you are not allowed to access this page.” message means a capability check failed for the requested admin screen or action. WordPress core uses current_user_can() throughout wp-admin; the message does not identify one specific fault. The user's role may have lost capabilities, user metadata may be missing, or a plugin may be applying an incorrect access rule.

Why This Happens

Role or capability loss

A user's role can be changed accidentally, or a role editor can remove capabilities that an admin screen requires. Manual database edits and incomplete environment restores can have the same effect. A user may still sign in successfully but lack manage_options, edit_posts, or another capability checked by the destination page.

WordPress evaluates capabilities for the current site. On multisite, being a network super admin and being a site administrator are related but distinct contexts, so test the exact screen that fails.

Plugin conflicts

Security, membership, white-label, and permissions plugins can filter capabilities or block admin routes. A bad rule may affect one page, one role, or every user. A caching plugin or misconfigured proxy can also serve an authenticated admin response to the wrong session, although properly configured WordPress admin pages should not be shared-cached.

Corrupted or missing user meta

WordPress stores role membership in a prefixed user-meta key such as wp_capabilities. Its value is a serialized PHP array. If the row is absent, empty, or malformed, WordPress cannot resolve the user's role. Direct SQL edits are especially prone to breaking the serialized value because string lengths and syntax must remain exact.

A table-prefix mismatch after migration

The database table prefix in $table_prefix inside wp-config.php must agree with capability meta keys. A migration might rename tables from wp2_ to wp_ while leaving wp2_capabilities and wp2_user_level in wp_usermeta. WordPress then looks for wp_capabilities, finds nothing, and treats the user as capability-less.

Diagnosing the Cause

Take a database backup before changing roles or user metadata. Run WP-CLI in the affected WordPress installation so it loads the correct configuration.

Confirm that WordPress recognizes at least one administrator:
```
wp user list --role=administrator
```
An empty result indicates a role-assignment problem, a prefix mismatch, or role definitions that a plugin altered. Record the numeric ID of the affected account.
Confirm the site URL and configured table prefix:
```
wp option get siteurl
wp config get table_prefix
```
The URL helps confirm that WP-CLI bootstrapped the intended site. If the prefix command returns wp_, WordPress expects capability metadata under wp_capabilities.
Inspect the expected capabilities entry:
```
wp user meta get 42 wp_capabilities
wp user meta list 42
```
Replace 42 with the real user ID. A healthy administrator value represents an array with administrator set to true. In the complete list, look for an absent key, an empty value, malformed serialized data, or wp2_capabilities when configuration expects wp_capabilities.
List active plugins and note those that alter roles, membership, login security, caching, or admin menus:
```
wp plugin list --status=active
```
Compare the list with recent updates or configuration changes. If only one admin screen fails, identify which plugin registered that screen and which capability its menu callback requires.
If WP-CLI reports filesystem or bootstrap warnings, inspect PHP and web-server logs. File ownership is not the usual cause of capability loss, but unwritable session, cache, or option storage can make authentication state appear inconsistent or prevent a repair from persisting.

Fixing Each Cause

Restore the intended role

Use WordPress APIs through WP-CLI instead of writing serialized SQL by hand:

wp user set-role 42 administrator

Only grant administrator access to a trusted account that should control the site. For a narrowly scoped requirement, add the specific capability instead:

wp user add-cap 42 edit_others_posts

Log out and back in after the change so WordPress creates a fresh authenticated session. If the role immediately disappears again, a plugin or deployment task is rewriting it.

Isolate a plugin conflict

Deactivate one likely permissions plugin at a time and retest the exact page:

wp plugin deactivate permission-plugin-slug

Do not disable every plugin on a production site without considering checkout, security, and authentication impact. Once the responsible plugin is identified, correct its access rule, update it, or replace it. Purge any improperly shared admin cache and configure /wp-admin/ plus authenticated requests to bypass full-page caching.

Recreate damaged capability metadata

wp user set-role normally recreates the correct capability entry for the configured prefix. Verify it afterward:

wp user set-role 42 administrator
wp user meta get 42 wp_capabilities
wp user list --role=administrator

For a nonstandard prefix, substitute the actual key when inspecting it. Avoid copying a raw serialized value between users unless you understand its role and site context. WordPress and WP-CLI should perform serialization.

Repair a prefix mismatch

First decide which prefix is authoritative by comparing $table_prefix with actual table names. Do not casually change the configuration on a live site because that can make WordPress look for an entirely different table set.

When the tables and configuration correctly use wp_ but user meta still uses wp2_, recreate each affected user's role through wp user set-role. Confirm the new wp_capabilities key and successful login before removing obsolete wp2_capabilities metadata. On multisite, capability keys include the site-specific prefix, so repair the relevant site rather than applying one global substitution.

Correct filesystem ownership only when logs support it

Make the PHP worker able to write only the directories the application actually needs. Do not solve an access-control error with broad world-writable permissions. After ownership is corrected, repeat the WordPress-level role repair and confirm the value persists across requests.

Preventing It From Happening Again

Keep a second, secured administrator account for recovery, restrict who can edit roles, and export role configuration before changing permissions plugins. Migration checks should compare table names, $table_prefix, and capability meta keys, then run a real administrator login test.

Nova includes managed WordPress core and plugin updates with daily automated GCS backups on its managed WordPress hosting. For help evaluating a migration or recovery path, contact the team.

FAQ

Why can I log in but not access an admin page?

Authentication proves who you are; authorization decides what you can do. Your login cookie may be valid while your role lacks the capability required by that page.

Does this message mean my password is wrong?

No. An incorrect password prevents login. This message usually appears after WordPress has identified the user and denied a capability check.

Can I fix the error directly in phpMyAdmin?

It is possible, but serialized capability values and prefixes are easy to damage manually. Prefer wp user set-role after taking a backup because it uses WordPress's own role APIs.

Why did the error appear after a migration?

The new environment may use a different table prefix while capability keys still contain the old one. A partial database restore, changed plugin set, or stale shared cache can also alter how WordPress resolves the user.