You log into WordPress with credentials that worked fine yesterday, and instead of the dashboard you get a single blunt line: "Sorry, you are not allowed to access this page." No error code, no explanation, just a locked door. It usually shows up right after a plugin update, a botched migration, or someone "cleaning up" user roles in phpMyAdmin. Here's how to get back in without nuking the site.

What This Error Actually Means

WordPress checks a capability (like manage_options) before it lets a logged-in user see an admin screen. This message means WordPress recognized your login, but the account it matched has no admin capabilities attached — or none at all. It's a permissions problem, not an authentication problem, which is why the password still works.

  • The wp_capabilities row for your user in wp_usermeta is empty, corrupted, or missing
  • $table_prefix in wp-config.php doesn't match the actual prefix used in the database
  • A security or membership plugin is intercepting the request and blocking the role check
  • On WordPress Multisite, the account isn't added as a member of that particular site
  • A "role manager" plugin got deactivated or deleted while it still had roles pointing at it

Step 1: Confirm You Can Still Reach phpMyAdmin

Everything below needs database access, so log into cPanel and open phpMyAdmin first. If you're not sure which database your site uses, open wp-config.php via File Manager and check DB_NAME near the top of the file. Note the $table_prefix value too — you'll need it in a minute.

Step 2: Check for a Table Prefix Mismatch

This is the single most common cause after a migration or a restored backup. In phpMyAdmin, look at the actual table names in the database — you might see wp7x2_usermeta while wp-config.php still says:

$table_prefix = 'wp_';

WordPress reads capabilities from {prefix}capabilities, so if the prefix in the config file doesn't match the tables that actually exist, it looks for wp_capabilities, finds nothing, and treats you as a subscriber with zero permissions. Fix it by editing $table_prefix to match the real prefix, save, and try logging in again.

Step 3: Restore Admin Capabilities Directly in the Database

If the prefix is correct, the row itself is likely damaged. In phpMyAdmin, open the SQL tab for your WordPress database and run:

SELECT * FROM wp_usermeta WHERE meta_key = 'wp_capabilities';

Find the row for your user_id (cross-reference against the wp_users table by email or username). If the meta_value is blank, truncated, or reads something odd, replace it:

UPDATE wp_usermeta
SET meta_value = 'a:1:{s:13:"administrator";b:1;}'
WHERE user_id = 1 AND meta_key = 'wp_capabilities';

UPDATE wp_usermeta
SET meta_value = '10'
WHERE user_id = 1 AND meta_key = 'wp_user_level';

Swap wp_ for your actual table prefix and 1 for your real user ID. If no row exists at all for that user, use INSERT instead of UPDATE. This is a serialized PHP array, so don't add extra spaces or change the character count in the string — that s:13: has to match the exact length of "administrator" or WordPress will fail to unserialize it and you'll be back where you started.

Step 4: Rule Out a Plugin Doing This on Purpose

Security plugins, membership plugins, and custom role editors are the second most common cause — especially if the lockout appeared right after an update. Rename the plugins folder via File Manager or SFTP to force-deactivate everything:

mv wp-content/plugins wp-content/plugins-disabled

Try logging in again. If that works, rename the folder back, then rename plugins one at a time (or check the plugin's changelog for anything mentioning "roles" or "capabilities") until you find the culprit. Update or replace it before re-enabling the rest.

Step 5: Check Multisite Site Membership

If this is a Multisite network, capabilities are stored per-site, not per-network. A user can be a super admin on the network and still get this exact error on an individual site they were never added to. The relevant meta key includes the site's blog ID, e.g. wp_3_capabilities for site ID 3. Either add the user to that site under Network Admin > Sites > [site] > Users, or run the same UPDATE query above against the correct wp_{blog_id}_capabilities row.

Step 6: Confirm With WP-CLI (If You Have SSH Access)

On a VPS or any plan with SSH, WP-CLI makes this much faster than manual SQL. From the site's root directory:

wp user list --role=administrator
wp user set-role youruser administrator

The first command shows who currently has admin rights (useful for confirming the account is really broken and not just mistyped). The second one repairs it in a single line, no serialized strings to get wrong.

Prevention

  • Take a database backup (or a full JetBackup snapshot in cPanel) before installing or updating any plugin that touches roles, permissions, or membership
  • Keep one "break glass" administrator account with a strong, separately stored password that no plugin ever restricts
  • After any migration or restore, always verify $table_prefix in wp-config.php against the live database before you do anything else
  • If you manage a Multisite network, document which users belong to which sites so membership gaps are obvious
  • Avoid hand-editing serialized data in phpMyAdmin when you can use WP-CLI or the WordPress admin UI instead — it's far less error-prone

Frequently Asked Questions

Why does this happen right after I restore a backup?

Backups often get restored into a database with a different table prefix than the original site expected, or the wp-config.php that ships with the backup doesn't match the new database name and prefix. Always double-check both against phpMyAdmin immediately after a restore.

Can I fix this without database access?

Only if the cause is a plugin, not a corrupted capabilities row. If renaming the plugins folder restores access, you're done without touching SQL. If it doesn't, you'll need phpMyAdmin or WP-CLI to repair the user meta directly.

I ran the SQL fix and I'm still locked out. What now?

Double-check you updated the row for the correct user_id and the correct table prefix, and that the serialized string wasn't altered by copy-paste (smart quotes are a common culprit). Also clear any object cache (Redis, LiteSpeed Cache) since a cached user session can mask a database fix for a few minutes.

Is this the same as the "briefly unavailable for scheduled maintenance" message?

No. That message means WordPress is mid-update and a .maintenance file got stuck. This error means you're logged in but lack permissions — the site itself is running fine for everyone else.

Will this affect other users on the site?

Usually not. It's almost always tied to one specific account's capabilities row, one plugin's role logic, or one Multisite membership gap — not the whole site's permission system. If every single user is locked out simultaneously, suspect a plugin conflict or a bad table prefix rather than individual account corruption.