WordPress "Sorry, you are not allowed to access this page"

What’s actually happening

You log in successfully — credentials accepted, no cookie error — then wp-admin throws this and dumps you out. It hits admins hardest: the account exists and the password is right, but WordPress reads zero capabilities for it and treats you as having no role. This is a WordPress-level permission check (current_user_can()), not an Apache/nginx 403. It frequently appears right after a database migration, a search-replace gone wrong, or a manual prefix change.

Common causes

• $table_prefix in wp-config.php doesn't match the actual table names (e.g. config says wp_ but the imported DB uses wp_abc1_) — so WP reads no user meta at all.
• The usermeta capabilities key is prefixed with the table prefix (wp_capabilities), and a search-replace that rewrote the prefix in the DB but not in wp-config.php (or vice-versa) orphaned it.
• The wp_capabilities or wp_user_level meta row for your user got deleted or set to an empty/serialized-broken value.
• The user_roles option (wp_user_roles) in wp_options is corrupt or missing, so no roles resolve for anyone.
• A migration plugin or manual export left the prefix in the data inconsistent — some rows on the old prefix, some on the new.

How to fix it

1. Match $table_prefix to the real tablesIn phpMyAdmin, look at the actual table names — say they're wp_abc1_options. Open wp-config.php and set $table_prefix = 'wp_abc1_'; to match exactly, including the trailing underscore. A prefix mismatch is the number-one cause and the quickest thing to rule out.
2. Inspect the capabilities meta rowIn the usermeta table, filter meta_key for {prefix}capabilities for your user_id. It should hold a:1:{s:13:"administrator";b:1;}. If the meta_key uses the wrong prefix, or the value is empty/garbled, that's your problem — fix the key name to match the live prefix.
3. Restore the admin capability via WP-CLIWith shell access: wp user list, then wp user add-role <id> administrator (or wp user set-role <id> administrator). WP-CLI rewrites the correctly-prefixed wp_capabilities meta for you, sidestepping manual serialized-data edits.
4. Repair serialized meta by hand if neededNo CLI? In phpMyAdmin set that user's {prefix}capabilities meta_value to a:1:{s:13:"administrator";b:1;} exactly — serialized strings count bytes, so a malformed length breaks it. Add a {prefix}user_level row of 10 if it's missing.
5. Rebuild roles if everyone is locked outIf no account can get in, wp_user_roles in wp_options may be gone. Restore it from a backup, or temporarily drop $wp_roles->use_db = false; logic by reinstalling the same WordPress version so default roles re-seed — then re-add custom roles.