---
title: "Fix \"Sorry, you are not allowed to access this page.\""
url: https://wpministry.co/errors/sorry-you-are-not-allowed-to-access-this-page/
description: "Your account lacks the capability the screen asks for. Its role is too low, the stored roles are damaged or a plugin is in the way. Nothing on the site is lost."
lang: en-US
---

Skip to content

# How to fix "Sorry, you are not allowed to access this page." in WordPress

WordPress shows this when the account you are logged in with lacks the capability a dashboard screen asks for. The account's role is too low, the roles in the database are damaged or stored under an old table prefix, or a plugin is in the way. Nothing on the site is lost.

By

WP Ministry

Published

October 7, 2026

Tested on

WordPress 7.1.4, PHP 8.3.36

## In short

- The message is about your account, not the site. Content and settings are untouched, and visitors still see the site.
- Three WP-CLI commands show the account's role and the site's roles, which tells the causes apart.
- After the table prefix changes, the two role keys in the database still carry the old prefix, and every administrator is refused.
- Rename those keys to the new prefix. It keeps every user's role and every custom role.
- When one screen alone refuses you, look at the plugins. One may be restricting it, or the screen's own plugin is switched off.

WordPress gives every account a role, and every role a list of capabilities: the things it may do. Each dashboard screen asks for one of them. When the account you are logged in with does not have it, WordPress stops and shows "Sorry, you are not allowed to access this page." in place of the screen, with the status 403.

Nothing has been lost. Your posts, pages, settings and users are where they were, and visitors still see the site. What is wrong is the record of what your account may do, or the place WordPress looks for that record.

## Find out which cause you have

WordPress keeps the site's roles in one row of the options table, and each user's role in the user meta table. Both are named with the table prefix that `$table_prefix` sets in `wp-config.php`. With the default prefix, `wp_`, they are `wp_user_roles` and `wp_capabilities`.

With WP-CLI, three commands show what WordPress finds there. Put your own username in place of `your-username`.

bash

```
wp user get your-username --field=roles
wp user list-caps your-username
wp role list
```

| The account's role | The list of roles | What it means |
| --- | --- | --- |
| A role below `administrator`, such as `subscriber` | The usual five | The account's role was changed. Use the first fix. |
| Nothing | Nothing | WordPress is looking under a different prefix. Use the second fix. |
| `administrator` | Nothing, or a role is missing | The stored roles are damaged. Use the third fix. |
| `administrator` | The usual five | The role has lost a capability (third fix), a plugin is refusing the screen (fourth), or the screen is not there (fifth). |

Two other faults look similar and are not this one. A page that says "Forbidden" in the web server's own words is a refusal before WordPress runs: see How to fix the 403 Forbidden error in WordPress (https://wpministry.co/errors/403-forbidden/). A login form that keeps coming back means you were never logged in: see How to fix a WordPress login page that keeps refreshing or redirecting (https://wpministry.co/errors/login-page-refreshing-and-redirecting/).

## Where it goes wrong

A page request passes through each of these in turn. This one comes from **WordPress itself**.

1. Browser
2. DNS
3. HTTPS
4. CDN or firewall
5. Web server
6. PHP
7. WordPress (this error comes from here)
8. Database and files

## What causes it

- ### The account's role does not include the screen
  Common
  The role was lowered, or the screen belongs to a higher role. On a multisite network, installing plugins and themes and managing users belong to the network's Super Admin, not to a site's Administrator.
  Fix: Give the account its Administrator role back, or Create a new administrator
- ### The table prefix changed and the role keys did not
  Common
  WordPress names the row that holds the roles, and the row that holds each user's role, with the table prefix. If the prefix changes and those names do not, it finds no roles and treats every account as having none.
  Fix: Rename the role keys to match the table prefix
- ### The stored roles are missing, or a role has lost a capability
  Sometimes
  Roles are kept in the database and code can change them. A capability taken from the Administrator role stays gone until something puts it back.
  Fix: Put WordPress's default roles back
- ### A plugin is refusing the screen
  Sometimes
  WordPress lets code change the answer each time a capability is checked, so a plugin can refuse a screen to an account whose role is complete.
  Fix: Rule out a plugin
- ### The address belongs to a plugin that is switched off
  Sometimes
  A screen that a plugin adds exists only while the plugin is active. Its address then gets this message, even for an administrator.
  Fix: Switch the screen's plugin back on

## How to fix it

### Give the account its Administrator role back

- Easy
- Low risk
- About 5 minutes
- Steps tested on WordPress 7.1.4

An Administrator has access to all the administration features of a single site. Every other role is refused the screens above it. On a multisite network, installing plugins and themes and managing users belong to the network's Super Admin, so a site's Administrator is refused those screens by design. Ask whoever runs the network.

1. #### Step 1: If another administrator can log in
   On the Users screen, they select the checkbox beside your account, choose Administrator in the "Change role to…" menu and select Change.
2. #### Step 2: With WP-CLI
   bash Copy

   ```
   wp user set-role your-username administrator
   ```

3. #### Step 3: With only a database tool
   Back up the database first. In the user meta table, find the row whose `user_id` is your account's ID (the `ID` column of the users table) and whose `meta_key` ends in `capabilities`. Give it the value below. This is the statement for the prefix `wp_` and the ID 1.
   sql Copy

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

4. #### Step 4: Reload the dashboard
   You do not need to log in again.

If the role changed and nobody on your team changed it, go through every account that can log in. How to audit a WordPress site for security weaknesses (https://wpministry.co/blog/audit-wordpress-site-security-vulnerabilities/) covers who should hold the Administrator role and what an account nobody can explain means.

**To undo it:** Set the role the account had before, the same way.

### Rename the role keys to match the table prefix

- Advanced
- Back up first
- About 20 minutes
- Steps tested on WordPress 7.1.4

When a site's tables are given a new prefix and `$table_prefix` is changed to match, during a move for example, the rows inside the tables keep their old names. WordPress then asks for the roles under the new prefix, finds nothing, and treats every account as having no role, administrators included. Everyone can still log in. Nobody can open the dashboard.

1. #### Step 1: Export the database
   `~/` is your home folder. Keep the file out of the folder the site is served from. Without WP-CLI, use the export in your host's database tool.
   bash Copy

   ```
   wp db export ~/before-prefix-fix.sql
   ```

2. #### Step 2: See which prefix is which
   The first line is the prefix WordPress uses now: the value of `$table_prefix`, and the start of every table's name. The other two show the keys as they are stored. If they begin with something else, that is the old prefix and this is your cause. If they begin with the same prefix, it is not: leave them alone.
   bash Copy

   ```
   wp db prefix
   wp db query "SELECT option_name FROM $(wp db prefix)options WHERE option_name LIKE '%user_roles'"
   wp db query "SELECT DISTINCT meta_key FROM $(wp db prefix)usermeta WHERE meta_key LIKE '%capabilities'"
   ```

3. #### Step 3: Write the three statements
   Here `new_` stands for the prefix in use and `old_` for the one on the keys. Put your own in place of both.
   Rename these three and no others. Not every name that begins with `wp_` is built from the prefix: the option `wp_page_for_privacy_policy`, for one, has that name on every site.
   rename-keys.sql Copy

   ```
   UPDATE new_options SET option_name = 'new_user_roles' WHERE option_name = 'old_user_roles';
   UPDATE new_usermeta SET meta_key = 'new_capabilities' WHERE meta_key = 'old_capabilities';
   UPDATE new_usermeta SET meta_key = 'new_user_level' WHERE meta_key = 'old_user_level';
   ```

4. #### Step 4: Run them
   Paste them into your database tool's SQL box, or save them as `rename-keys.sql` in the site's folder and run:
   bash Copy

   ```
   wp db query < rename-keys.sql
   rm rename-keys.sql
   ```

5. #### Step 5: Reload the dashboard
   The login you have still stands. If nothing changes and the site has a persistent object cache, WordPress may still be using what it stored before the change. Clear it with `wp cache flush` or from your host's panel.

Renaming keeps every user's role and every custom role. A move changes addresses as well: How to move WordPress from a subdirectory to the root of your domain (https://wpministry.co/blog/move-wordpress-subdirectory-root/) and How to change your WordPress URL without locking yourself out (https://wpministry.co/blog/change-wordpress-url/) cover those.

**To undo it:** Run the same statements with the two prefixes swapped, or restore the export.

### Put WordPress's default roles back

- Takes care
- Back up first
- About 10 minutes
- Steps tested on WordPress 7.1.4

Roles and their capabilities are stored in the database, and code can add to them or take from them. A capability taken from the Administrator role stays gone after the code that took it has gone too.

1. #### Step 1: Reset the roles
   It names each role and what it did, for example `Restored 1 capability to and removed 0 capabilities from 'administrator' role.`
   bash Copy

   ```
   wp role reset --all
   ```

2. #### Step 2: Reload the screen that refused you
   If the whole list of roles was missing, the reset writes the five default roles again. Custom roles that were in the lost list are not brought back.

**To undo it:** Restore the database export.

### Rule out a plugin

- Easy
- Low risk
- About 10 minutes
- Steps tested on WordPress 7.1.4

WordPress lets code change the answer each time it checks a capability. A plugin that does so can refuse a screen while the account's role, and the list of capabilities WP-CLI prints for it, look complete.

1. #### Step 1: Switch every plugin off
   Without WP-CLI, How to deactivate WordPress plugins when you are locked out of the dashboard (https://wpministry.co/blog/deactivate-wordpress-plugins-locked-out/) gives the other ways, from a renamed folder to the list in the database.
   bash Copy

   ```
   wp plugin deactivate --all
   ```

2. #### Step 2: Open the screen again
   If it opens, a plugin was refusing it.
3. #### Step 3: Switch them back on one at a time
   Open the screen after each one. The plugin that brings the message back is the cause. Look in its settings for a rule about who may see what.
   bash Copy

   ```
   wp plugin activate plugin-folder-name
   ```

**To undo it:** Activate the plugins again.

### Switch the screen's plugin back on

Look at the address. One that contains `page=`, such as `/wp-admin/admin.php?page=example-reports`, is a screen that a plugin adds. While that plugin is switched off or deleted the screen is not registered, and WordPress answers its address with this message, even for an administrator. A bookmark or an old link is enough to land on one.

1. #### Step 1: See which plugins are switched off
   bash Copy

   ```
   wp plugin list --status=inactive --field=name
   ```

2. #### Step 2: Switch the one you need back on
   bash Copy

   ```
   wp plugin activate plugin-folder-name
   ```

3. #### Step 3: Open the address again
   If the plugin was removed on purpose, nothing is wrong. Open the dashboard from `/wp-admin/` and delete the bookmark.

**To undo it:** Deactivate the plugin again.

### Create a new administrator

- Takes care
- Low risk
- About 10 minutes
- Steps tested on WordPress 7.1.4

Use this when no account you can log in to is an administrator.

1. #### Step 1: See whether any administrator is left
   bash Copy

   ```
   wp user list --role=administrator --fields=ID,user_login,user_email
   ```

2. #### Step 2: Create one
   WP-CLI makes a password and prints it. Keep it in a password manager. In the WP-CLI command builder (https://wpministry.co/tools/wp-cli-command-builder/) you choose a job, fill in what it needs, and copy the command with its flags in place.
   bash Copy

   ```
   wp user create new-admin person@example.com --role=administrator
   ```

3. #### Step 3: Log in with it and put the other accounts right
   On the Users screen, give each person the role they should have.

**To undo it:** Delete the new account.

## When to get help

If the account and the roles both look right, the plugins are off and the screen still refuses you, stop editing the database by hand. A wrong value in these rows leaves every account without a role. The same goes for a role that changed when nobody changed it, where how it happened matters more than putting it back.

## Common questions

Why did this start right after I moved the site?

Most likely the table prefix changed and the role keys did not. The tables carry the new prefix, but the row that holds the roles and the rows that hold each user's role still carry the old one, so WordPress finds no roles. The second fix renames them.

Is "You do not have sufficient permissions to access this page." the same error?

Yes. That was the wording in older versions: WordPress 4.5 has it at the point in the code where current versions have the new sentence. The causes and the fixes are the same.

Why does logging in take me to the home page instead of the dashboard?

After a login, WordPress sends an account that cannot edit posts to its profile, and an account that cannot even read to the site's home page. Landing on the home page with the right password means the account has no capabilities at all. That points to the prefix (second fix) or to missing roles (third fix).

## More on this subject

- WordPress errors and troubleshooting: https://wpministry.co/topics/wordpress-troubleshooting/
- Guide WordPress uptime monitoring: what a check sees and what it misses: https://wpministry.co/blog/wordpress-uptime-monitoring/
- Guide How to update the PHP version of a WordPress site: https://wpministry.co/blog/update-php-version-wordpress/
- Glossary term REST API: https://wpministry.co/glossary/rest-api/
- Guide Slow WordPress admin: how to find the cause and fix it: https://wpministry.co/blog/slow-wordpress-admin/
- Resource WooCommerce checkout is down: a runbook: https://wpministry.co/resources/woocommerce-checkout-down-runbook/
- Guide WordPress site not showing up on Google: what to check, in order: https://wpministry.co/blog/wordpress-site-not-on-google/

## Would you rather we fixed it?

Quick Fix is $49. One issue, one site, up to about an hour. No fix, no fee. 30-day warranty.

More about this work: One-time WordPress fix (https://wpministry.co/services/one-time-fix/)

May we measure how this site is used?

A yes notes the pages of this visit and loads Google Analytics. A no keeps and loads nothing. See the cookies page (https://wpministry.co/legal/cookies/).

If you say yes, we note the pages you look at during this visit and load Google Analytics. If you say no, nothing is kept and nothing is loaded. The site works the same either way. The cookies page (https://wpministry.co/legal/cookies/) has the details.

## Structured data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://wpministry.co/#organization",
      "name": "WP Ministry",
      "url": "https://wpministry.co/",
      "logo": "https://wpministry.co/brand/logo.png",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "1309 Coffeen Ave STE 1200",
        "addressLocality": "Sheridan",
        "addressRegion": "WY",
        "postalCode": "82801",
        "addressCountry": "US"
      },
      "sameAs": [
        "https://www.linkedin.com/company/wp-ministry/",
        "https://x.com/wpministryco",
        "https://www.instagram.com/wpministryco/",
        "https://www.facebook.com/wpministryco",
        "https://www.tiktok.com/@wpministryco",
        "https://www.pinterest.com/wpministryco/",
        "https://www.youtube.com/channel/UCOZRuAukk5QSTRPG6BaHl3Q"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://wpministry.co/#website",
      "name": "WP Ministry",
      "url": "https://wpministry.co/",
      "inLanguage": "en-US",
      "publisher": {
        "@id": "https://wpministry.co/#organization"
      }
    },
    {
      "@type": "TechArticle",
      "@id": "https://wpministry.co/errors/sorry-you-are-not-allowed-to-access-this-page/#article",
      "headline": "How to fix \"Sorry, you are not allowed to access this page.\" in WordPress",
      "description": "Your account lacks the capability the screen asks for. Its role is too low, the stored roles are damaged or a plugin is in the way. Nothing on the site is lost.",
      "url": "https://wpministry.co/errors/sorry-you-are-not-allowed-to-access-this-page/",
      "mainEntityOfPage": "https://wpministry.co/errors/sorry-you-are-not-allowed-to-access-this-page/",
      "inLanguage": "en-US",
      "image": "https://wpministry.co/og/errors/sorry-you-are-not-allowed-to-access-this-page.png",
      "author": {
        "@id": "https://wpministry.co/#organization"
      },
      "publisher": {
        "@id": "https://wpministry.co/#organization"
      },
      "datePublished": "2026-10-07T00:00:00.000Z",
      "dateModified": "2026-10-07T00:00:00.000Z"
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Home",
          "item": "https://wpministry.co/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Error fixes",
          "item": "https://wpministry.co/errors/"
        },
        {
          "@type": "ListItem",
          "position": 3,
          "name": "How to fix \"Sorry, you are not allowed to access this page.\" in WordPress"
        }
      ]
    }
  ]
}
```