If WordPress shows “Sorry, You Are Not Allowed to Access This Page” after you have logged in, your password worked but the account failed an authorization check for the screen you opened. In most cases, the user’s administrator role or a specific capability such as manage_options has been removed, downgraded, or made unavailable.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Start with the least destructive check: confirm the account’s role with WP-CLI or in the database. If the error began after a staging sync, database restore, plugin change, or theme edit, reverse that change or restore a known-good backup. Only then isolate plugins and inspect custom capability code.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What the WordPress error means
WordPress can authenticate you successfully and still refuse to open an administration page. Authentication answers “Who are you?” Authorization answers “Is this user allowed to perform this action?” This message indicates that the second test failed.
An administration screen normally calls current_user_can() with the capability it requires. If the check returns false, WordPress commonly stops the request with its standard “not allowed” message. The account therefore exists and the login session is valid; changing the password will not restore access unless the login itself is also failing.
#1 Best Overall
Capability checks, roles, and meta capabilities
current_user_can() checks the current user’s capabilities and is a wrapper around user_can() that uses the current user object. WordPress converted this implementation in version 5.8.0. A role is a bundle of capabilities, but a screen may test one capability rather than the role name.
Some checks use meta capabilities such as edit_post or edit_user. WordPress maps those to primitive capabilities such as edit_posts and edit_others_posts through map_meta_cap(). That is why restoring a role is usually safer than adding one guessed capability by hand.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11WordPress stores role definitions in the options table under the user-roles setting (normally the site’s database prefix followed by user_roles) and stores each user’s assigned role data in user metadata. Checking roles directly in custom code is discouraged because capability mapping can make a direct role comparison unreliable.
Before changing anything: identify the scope
Record the exact URL or menu item that produces the message, the affected username, and when the problem began. This distinguishes a site-wide role problem from one broken screen.
- Every administration screen fails: suspect a lost administrator role, damaged role data, or a database-prefix mismatch.
- Only one settings page fails: the account may still be an administrator but lack a capability such as
manage_options, or a plugin may be enforcing an incorrect check. - Only one user fails: inspect that user’s role and metadata first.
- Several users fail immediately after a migration or restore: compare the database and
wp-config.phpprefixes before editing individual accounts. - The problem started after a plugin, theme, or code change: isolate that change after confirming the role.
Make a database backup before editing user metadata, role options, or configuration. A role correction is normally small, but a mistyped serialized value or an edit against the wrong database can affect more than one account.
Choose the safest recovery route
| Method | Access required | Typical speed | Risk to live data | Best use |
|---|---|---|---|---|
| Dashboard role check | Another administrator account with dashboard access | Fast | Low | Confirming or correcting a single user without touching the database directly |
| WP-CLI role change | Shell access and WP-CLI | Fast | Low when the user ID is verified | Restoring an administrator role from the command line |
| Database metadata edit | Database administration access | Fast, but manual | Higher | When no dashboard or WP-CLI access exists and the backup is verified |
| Plugin-directory rename | FTP or the host’s file manager | Fast | Low to site data, but plugins stop running | Testing whether a plugin causes the capability failure |
| Backup restoration | A known-good site and database backup | Depends on the host | Can discard newer changes | A recent sync, restore, or configuration change clearly caused the failure |
Use one route at a time and test after each change. That preserves a useful cause-and-effect trail and makes it easier to undo the last action.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsFix 1: check the user’s role from the dashboard
This route requires a second account that can still reach the Users screen.
- Sign in with the unaffected administrator account.
- Open Users and select the affected account.
- Inspect the Role field. If the account was changed to Subscriber, Contributor, Author, or Editor, select Administrator and save the user.
- Sign out, sign back in as the affected user, and open the previously blocked screen.
If the account already says Administrator but one screen remains blocked, the role may have had a capability removed. A role-management plugin such as User Role Editor can display capabilities; check for the capability the screen requires, including manage_options for many settings pages or edit_pages for page editing. Change only the missing permission you have identified, then test again.
Do not grant every capability as a trial. Broad permissions can create a security problem and can hide the plugin or theme defect that caused the failure.
Fix 2: restore the role with WP-CLI
WP-CLI is the quickest controlled fix when you have shell access. First verify the site path and the user ID; do not guess an ID from a username that may be duplicated or mistyped.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Change to the WordPress installation directory on the server.
- List users or otherwise confirm the affected account’s numeric ID.
- Set the role with
wp user set-role <user_id> administrator. - Run the command against the intended WordPress installation and database, then sign in again.
The command changes the assigned role rather than manually constructing serialized metadata. If it reports that the user does not exist, stop and verify the site path, database connection, username, and ID before trying again.
If the role is restored but the same page still fails, the problem may be a capability removed from the administrator role or code that is denying access independently of the role. Continue with the plugin and theme isolation steps rather than repeatedly assigning the role.
Fix 3: repair the user metadata in the database
Use this method only after taking a database backup and confirming that you are editing the database used by the affected site. Database table prefixes are not always wp_; substitute the actual prefix in every table and metadata key.
Locate the user
- Open the site’s user table and identify the affected user’s numeric ID.
- Open the corresponding user metadata table.
- Filter rows for that user ID and find the capabilities metadata key, normally
<prefix>capabilities(often shown aswp_capabilitieson a default installation). - Check the role value. For an administrator, one documented representation is
a:1:{s:13:"administrator";b:1;}. - Check the companion user-level value, normally
<prefix>user_level. The administrator value described in the troubleshooting guidance is10.
The serialized string must match PHP’s lengths and punctuation exactly. Do not add spaces, smart quotes, or a different character count. If your site uses a custom prefix, the key name changes but the serialized administrator value does not.
Make and verify the edit
- Export or otherwise preserve the original metadata rows.
- Change only the affected user’s capability and level rows, using the exact values appropriate to the administrator role.
- Save the change and clear any object or page cache that could preserve the old session or menu.
- Start a new browser session, sign in again, and test the original screen.
If the account immediately loses the role again, a plugin, theme, scheduled task, migration process, or synchronization job is rewriting the metadata. Fix that writer instead of repeatedly repairing the row.
Fix 4: check for a database-prefix mismatch
WordPress needs the prefix configured in wp-config.php to match the tables that contain the site’s roles and user metadata. A migration, restored backup, or manual configuration edit can leave the application looking in one prefix while the role data remains under another.
- Open
wp-config.phpand note the value assigned to$table_prefix. - In the database, identify the tables that begin with that exact prefix.
- Confirm that the users, user metadata, options, and role data for this site use the same prefix.
- Look for a second set of tables with a different prefix that contains the expected users and role information.
- Correct the configuration or database arrangement only after taking a backup and confirming which set is the live site.
A prefix mismatch can make WordPress appear to have no role data, so assigning a role in the wrong table will not solve the error. If you are uncertain which database belongs to the site, ask the host or compare the database name and credentials in wp-config.php before changing anything.
Fix 5: isolate plugins when the role is correct
Plugin code can add capability checks or alter role definitions. If the dashboard is unreachable, disable plugins without deleting their files:
Rank #4
- Use FTP or the host’s file manager to open the site’s
wp-contentdirectory. - Rename the
pluginsdirectory to a temporary name such asplugins.hold. - Start a new login session and test the blocked page.
- If access returns, rename the directory back to
plugins. - Reactivate plugins one at a time, testing the page after each activation, until the failing plugin is identified.
Renaming the directory disables all standard plugins at once, so forms, caching, security rules, and other features may stop temporarily. Do not leave production functionality disabled longer than necessary. Once the offending plugin is identified, update it if a compatible release exists, remove its faulty capability rule, or restore the site from a backup made before the change.
If renaming the directory has no effect, restore the original name before moving on. The failure may be in the active theme, a must-use plugin, a network-level plugin, or the stored role data rather than in a standard plugin.
Fix 6: inspect theme and custom capability code carefully
General troubleshooting reports include faulty plugin or theme capability checks as a cause. Code in the active theme’s functions.php is not established as a universal cause, so treat this branch as a site-specific inference, especially when the failure began immediately after a snippet was added.
With a backup and a way to restore the file, search recent changes for code that calls or modifies:
current_user_canadd_capremove_capset_rolemap_meta_cap- hooks such as
initthat run on every request
Comment out or revert only the recent, relevant change, then test with a fresh session. Do not delete an entire theme file to test one snippet. If the code belongs to a custom plugin or theme supplied by a developer, provide the exact blocked URL, user role, and recent change so the developer can reproduce the capability decision.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Fix 7: restore a known-good backup
Restoration is appropriate when a staging synchronization, database restore, migration, or manual change clearly precedes the error and you have a backup from before that event. Prefer a backup whose database and files belong to the same point in time.
Best Value
- Confirm the backup date and what it contains: database, uploads, plugins, themes, and configuration.
- Export or snapshot the current site first if the host permits it, so newer content is not irretrievably lost.
- Restore in the host’s documented order, commonly database and files as one matched set.
- Test login, the affected administration page, publishing, media, and any forms before declaring the recovery complete.
- Investigate the sync or change that caused the role loss before repeating it.
A restore can remove legitimate edits made after the backup, so use it for a confirmed regression rather than as the first response to an isolated missing capability.
Why the error can return after a successful fix
Repeated role loss is evidence of an ongoing writer or a mismatch, not a reason to keep editing the same user row. Check these possibilities in order:
Recommended Free Tools
- A deployment or staging-sync job is copying lower-privilege user metadata over production.
- A restored database contains an older role definition or uses a different prefix.
- A plugin or theme runs
set_role,add_cap, orremove_capduring initialization. - A role-management tool saved an incomplete role definition.
- You corrected one site in a multisite installation while the blocked screen belongs to another site’s role context.
Capture the time of each change and compare it with deployment logs, scheduled tasks, plugin activation, and database imports. Once the writer is removed or corrected, assign the intended role one final time and verify it in a new session.
Verification checklist after access returns
- The affected user can open the original screen without the error.
- The role shown in the Users screen matches the intended role.
- The user can perform only the actions that role is meant to permit.
- Other administrator accounts retain access.
- Plugins, the active theme, caching, and scheduled tasks still operate normally after any isolation test.
- The database backup or pre-edit export is stored safely.
- The change that caused the permission loss has been identified or documented as unresolved.
Preventing another authorization failure
Keep production and staging databases clearly separated, and review deployment procedures that copy users, user metadata, or the options table. A file-only deployment should not silently overwrite production role data with a lower-privilege staging snapshot.
Record intentional role changes and limit administrator access to accounts that need it. When adding custom access rules, test both an administrator and a lower-privilege account in a staging environment. Use capability checks for authorization instead of direct role-name comparisons, because WordPress maps meta capabilities according to the object and context.
Maintain recent, restorable backups of both the database and files. A backup that contains only uploads cannot restore role metadata, while a database-only restore may leave plugin or theme code that recreates the problem. After migrations and restores, test a real administrator login and at least one restricted account before handing the site back to editors.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
