Fixing 'Sorry, you are not allowed to access this page' in WordPress Admin

intermediate📝 WordPress2026-04-01| WordPress (all versions), Linux/Apache/Nginx, PHP 7.4+, MySQL/MariaDB

Error Message

Sorry, you are not allowed to access this page.
#wordpress#permissions#user-roles#capabilities#wp-admin#403

TL;DR: The Quick Fix

It’s a frustrating moment when you log in and get blocked by a single line of text. If you’re locked out right now, try these three steps to regain access:

  • Sync Your Database Prefix: Check that $table_prefix in wp-config.php matches the keys in your wp_usermeta table.
  • Refresh .htaccess: Rename the file to .htaccess_old to bypass custom server rules.
  • Deactivate Plugins: Temporarily rename your wp-content/plugins folder to plugins_old using FTP or SSH.

What is Actually Happening?

Think of this error as a internal 403 Forbidden message. Unlike a server-level block, WordPress itself is deciding that your account—while successfully logged in—doesn't have the right 'capabilities' to see the page you requested. This often happens after a site migration where about 80% of lockouts stem from a single mismatched line in the configuration file.

Common culprits include:

  • Mismatched database prefixes (the #1 cause after moving a site).
  • Security plugins like Wordfence or Sucuri blocking your specific IP.
  • Incorrect file permissions that prevent WordPress from reading its own core files.
  • PHP version mismatches, especially if your host recently updated to PHP 8.x.

Step-by-Step Fixes

1. Verify the Database Table Prefix

WordPress stores your admin permissions in the database using the table prefix as part of the key name. If you changed your prefix from wp_ to wp_secure_ in wp-config.php but didn't update the rows inside the database, WordPress will think you are a 'subscriber' with zero permissions.

First, open wp-config.php and locate this line:

$table_prefix = 'wp_custom_';

Next, use phpMyAdmin to look at your wp_usermeta table. Browse the meta_key column. If your prefix is wp_custom_, you should see keys named wp_custom_capabilities. If they still say wp_capabilities, you've found the problem. Run these SQL commands to sync them:

UPDATE `wp_custom_usermeta` SET `meta_key` = 'wp_custom_capabilities' WHERE `meta_key` = 'wp_capabilities';
UPDATE `wp_custom_usermeta` SET `meta_key` = 'wp_custom_user_level' WHERE `meta_key` = 'wp_user_level';
UPDATE `wp_custom_options` SET `option_name` = 'wp_custom_user_roles' WHERE `option_name` = 'wp_user_roles';

2. Set Correct File Permissions

Incorrect permissions are a major security risk. If your folders are set to 777, you're leaving the door wide open for hackers; if they are too restrictive, you get locked out. WordPress needs a very specific balance to run scripts properly.

Standard permissions should be:

  • Folders: 755 (Read/Write/Execute for owner, Read/Execute for others).
  • Files: 644 (Read/Write for owner, Read-only for others).
  • wp-config.php: 600 or 640 for maximum security.

Run these commands via SSH to reset your entire directory tree safely:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

I usually use the Unix Permissions Calculator on ToolCraft to visualize these settings. It helps ensure I'm not accidentally granting write access to the public.

3. Reset Your .htaccess File

A single typo in your .htaccess file can break your admin dashboard. Security plugins often add hundreds of lines of code here that might conflict with your login. To test this, delete your current file and replace it with this default WordPress block:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

4. Create an Emergency Admin User

When your user data is corrupted beyond repair, you can bypass the database entirely by injecting a new admin through your theme. Paste this snippet into your theme's functions.php file:

function temp_admin_account() {
    $user = 'recovery_admin';
    $pass = 'SecurePass!2024';
    $email = 'admin@yoursite.com';
    if ( !username_exists( $user ) ) {
        $user_id = wp_create_user( $user, $pass, $email );
        $user_obj = new WP_User( $user_id );
        $user_obj->set_role( 'administrator' );
    }
}
add_action('init','temp_admin_account');

Refresh your site once, log in with these new credentials, and fix your main account. Don't forget to delete this code as soon as you are back in.

How to Stay Unlocked

To prevent this from happening again, always keep a recent backup. I recommend using a staging environment whenever you change database prefixes or install heavy security suites. Finally, audit your users twice a year to ensure your 'Administrator' role hasn't been stripped of its core capabilities by a buggy plugin update.

Related Error Notes