How to Fix the Facebook Link Thumbnail Not Working Error
February 7, 2026
WordPress session expired: Guide To Fix It Quickly
February 10, 2026You're locked out of your own WordPress dashboard. The screen just says "Sorry, you are not allowed to access this page," and nothing you click makes it go away.
This WordPress admin access error usually comes from a corrupted user role, a plugin conflict, or a mismatched database table prefix in wp-config.php. It can hit after a migration, a core update, or even a routine plugin update that changed something it shouldn't have.
This guide covers exactly how to fix "sorry, you are not allowed to access this page" step by step. You'll learn how to check your role in the wp_usermeta table, verify URL settings, disable plugins via FTP, reset file permissions, repair your MySQL database, and create a new admin user manually if nothing else works.
What Does "Sorry, You Are Not Allowed to Access This Page" Mean?
"Sorry, you are not allowed to access this page" is a WordPress permissions error. It appears when a logged-in user tries to reach a page their current role doesn't have authorization for.
Most people see it when trying to open the wp-admin dashboard. But it can also show up on specific settings pages, plugin screens, or theme editors.
This is not a server error. It's not a 403 Forbidden from Apache or Nginx. WordPress itself is blocking you at the application level because the current_user_can() check fails for whatever capability that page requires.
WordPress powers over 43% of all websites on the internet, according to W3Techs. With that many installations running, this particular error ranks among the most commonly reported admin access problems in support forums.
The confusing part? You might have been an administrator five minutes ago. A plugin update, a migration, a database edit, or even a WordPress core update can silently change your role assignment in the database. And then you're locked out.
Here's what typically triggers it:
- Your user role in the
wp_usermetatable got corrupted or reassigned - The database table prefix in
wp-config.phpdoesn't match your actual tables - A security plugin like Wordfence or iThemes Security changed your permission settings
- The
siteurlorhomevalues inwp_optionsare wrong after a migration
One thing to keep in mind. A Patchstack report from 2025 found 11,334 new vulnerabilities in the WordPress ecosystem that year, a 42% increase over 2024. Roughly 96% of those came from plugins. So plugin-related permission problems are far from rare.
The good news is this error almost always comes from a fixable configuration problem. You just need to figure out which piece moved.
WordPress User Roles and How They Trigger This Error
WordPress has a built-in role system that controls what each user can and can't do. If your role data gets corrupted or reassigned, the dashboard locks you out immediately.
The Role Hierarchy
Administrator has full access to everything. Site settings, plugins, themes, user management, database tools. All of it.
Editor can manage and publish posts from any user but can't touch plugins or site settings. Author publishes and manages only their own posts. Contributor writes drafts but can't publish. Subscriber can only manage their profile.
Each role carries a set of capabilities. "install_plugins," "manage_options," "edit_theme_options," and so on. When you try to load a page in wp-admin, WordPress runs a current_user_can() check against your stored capabilities. If the answer is no, you get the error.
Where Role Data Lives in the Database
Your role assignment sits in two places inside the wp_usermeta table: the wp_capabilities meta key and the wp_user_level meta key.
For an administrator, wp_capabilities should contain a:1:{s:13:"administrator";b:1;} and wp_user_level should be 10.
If either value is wrong, empty, or pointing to a lower role, WordPress treats you as unauthorized. Took me a while to figure this out the first time I ran into it, because nothing else on the site looked broken. The front end loaded fine. Only the admin side was blocked.
SecurityWeek reported that 7,966 new WordPress vulnerabilities were found in 2024 alone. About 43% of those could be exploited without authentication. That's the kind of environment where security plugins aggressively modify user capabilities, sometimes catching legitimate admins in the process.
Common Reasons Your Role Changes Without Warning
- A security plugin reset roles during a scan or lockout event
- A migration tool failed to carry over the usermeta table correctly
- Someone manually edited the database and made a typo
- A WordPress core update partially failed mid-process
Your mileage may vary, but in my experience, the plugin conflict scenario happens more than anything else.
Check Your User Role in the Database
This is the fix that resolves the problem most often. If your role data is wrong in the database, no amount of plugin toggling or file editing will help. You need to go straight to the source.
Accessing phpMyAdmin
Log into your hosting panel. cPanel, Plesk, whatever your host provides. Look for phpMyAdmin under the databases section.
If you're on managed WordPress hosting like SiteGround or Bluehost, the path might be slightly different, but phpMyAdmin is almost always available somewhere in the dashboard. Some hosts bury it under "Advanced" or "Database Tools."
Finding Your User ID
Open your WordPress database and click on the wp_users table. Find the row with your username or email address. Note the ID number in the first column.
If you have multiple admin accounts, make sure you're looking at the right one. Sounds obvious, but I've seen people fix the wrong account and wonder why nothing changed.
Checking and Fixing wp_capabilities
Now open the wp_usermeta table. Filter or search for your user ID.
Look for two rows:
| Meta Key | Expected Value for Admin |
|---|---|
| wp_capabilities | a:1:{s:13:"administrator";b:1;} |
| wp_user_level | 10 |
If the wp_capabilities value shows "subscriber" or "editor" or is completely empty, that's your problem. Click Edit and replace it with the correct serialized string above.
Do the same for wp_user_level. Set it to 10.
Watch the table prefix. If your tables don't start with wp_, the meta keys will match whatever prefix your installation uses. So if your prefix is wpc_, you're looking for wpc_capabilities and wpc_user_level instead.
Save your changes, clear your browser cache, and try logging into wp-admin again.
Verify the Site URL and WordPress URL Settings
Mismatched URLs in the database are one of those problems that looks like a permissions error but isn't, technically. WordPress gets confused about where it lives, and the login redirect breaks.
What Goes Wrong
The wp_options table stores two values that WordPress uses for every page load: siteurl and home.
siteurl tells WordPress where the core files live. home tells it what URL visitors see. These two need to match your actual domain and protocol.
After a migration, SSL switch, or domain change, these values often end up wrong. Maybe one says http:// and the other says https://. Or the old domain is still in there. Either way, WordPress can't properly authenticate your session, and the admin panel blocks you.
Fixing It Through phpMyAdmin
Open your database in phpMyAdmin. Go to the wp_options table. Look for the rows where option_name is siteurl and home.
Both values should be your current, correct URL with the right protocol. Something like https://yourdomain.com. No trailing slash.
Edit both rows if they're wrong. Save.
Alternative: wp-config.php Override
If you'd rather not touch the database directly (or you keep getting locked out before you can fix it), add these two lines to your wp-config.php file via FTP or your hosting file manager:
define('WP_HOME', 'https://yourdomain.com'); define('WP_SITEURL', 'https://yourdomain.com');
These constants override whatever is in the database. Useful as a quick fix, but you'll want to correct the database values eventually and remove these lines. Leaving hardcoded URL overrides in your config file can cause headaches later if you ever move the site again.
Building websites that work properly after migration is one of those web designer skills that separates beginners from experienced developers. Getting URL handling right is a big part of that.
Check the wp-config.php File for Errors
The wp-config.php file is the single most important configuration file in any WordPress installation. One wrong value and your admin access disappears.
Table Prefix Mismatch After Migration
This is the one that catches people off guard.
Your wp-config.php file contains a $table_prefix variable. By default, it's set to wp_. But many hosts and migration tools change it for security reasons.
The problem happens when the prefix in your config file doesn't match the actual table names in your database. If wp-config.php says wp_ but your tables are named wpc_users, wpc_options, etc., WordPress can't find your role data. It can't find anything, really. But the error that surfaces is usually the permissions message.
WP Engine's documentation confirms this is a recurring issue, especially after migrations between hosts that use different default prefixes.
To check:
- Open
wp-config.phpvia FTP or file manager - Find the line that starts with
$table_prefix - Open phpMyAdmin and look at your actual table names
- Make sure they match
If they don't, change the $table_prefix value in wp-config.php to match what's actually in the database. Don't rename the tables. That's riskier.
Multisite Configuration Errors
WordPress Multisite adds another layer of complexity. The wp-config.php file contains extra constants like MULTISITE, SUBDOMAIN_INSTALL, DOMAIN_CURRENT_SITE, and PATH_CURRENT_SITE.
If any of these are wrong or missing, subsites and even the main site dashboard can throw the "not allowed" error. The permissions system in Multisite is stricter because it distinguishes between regular administrators and Super Admins.
Multisite is powerful, but it's also where I've seen the most bizarre permission failures. One wrong constant and the whole network locks up.
Other wp-config.php Issues to Check
Database credentials: If DB_NAME, DB_USER, DB_PASSWORD, or DB_HOST are incorrect, WordPress may partially load but fail on authentication checks.
Debug mode: Adding define('WP_DEBUG', true); can reveal PHP errors that point to the actual problem. Took me forever to start doing this consistently, but it saves hours every time.
Anyone building sites professionally knows how important proper configuration management is. It falls into the same category as understanding web design elements and server-side requirements. You can build the most beautiful front end in the world, but if wp-config.php is broken, nobody's getting in.
Disable Plugins via FTP or File Manager
Can't access wp-admin to deactivate plugins the normal way? That's the whole point of this error. You need to go around WordPress entirely.
Why Plugins Cause This Error
Security plugins are the number one offender. Wordfence, iThemes Security (now Solid Security), Sucuri. They all modify user capabilities or add access restrictions as part of their protection features.
Sometimes a plugin update changes how it handles permissions. Sometimes a caching plugin serves a stale authentication state. And membership plugins that create custom roles can override the default WordPress capability checks entirely.
Patchstack's 2025 report found that 96% of WordPress vulnerabilities came from plugins. It makes sense. Plugins touch everything, and they're written by thousands of different developers with different coding standards.
The FTP Method
Connect to your server using an FTP client like FileZilla. You can also use the file manager in cPanel or Plesk if your host provides one.
Go to /wp-content/ and find the plugins folder. Rename it to something like plugins-disabled.
That's it. WordPress can't load plugins from a folder it can't find. Try accessing wp-admin now.
If you're back in, the problem was definitely a plugin. Rename the folder back to plugins, then reactivate each plugin one at a time from the dashboard. The one that triggers the error again is your culprit.
What to Do When You Find the Culprit
You have a few options.
Update the plugin. If there's a newer version, the conflict might already be patched.
Check the plugin's settings. Some security plugins have role-management or access-restriction features that might be misconfigured.
Replace the plugin. If it's a known conflict with your theme or other plugins, look for an alternative. The WordPress plugin directory has over 60,000 free options.
Contact the developer. If the plugin is actively maintained, file a support ticket. Include your WordPress version, PHP version, and the exact error message.
It's worth mentioning that a well-designed website with good UX depends on everything working behind the scenes. A single plugin conflict can take down the admin experience even while the public-facing site looks fine. That disconnect is what makes this error so frustrating.
Switch to a Default Theme
Themes can break admin access just like plugins can. If a custom theme has role-manipulation code in its functions.php file, or if a theme update introduced a compatibility problem, the "sorry, you are not allowed to access this page" error shows up.
You can't switch themes from the dashboard when you're locked out. So you go around it.
How to Force a Theme Switch via FTP
Connect to your server with FileZilla or your hosting file manager. Go to /wp-content/themes/.
Find your active theme's folder and rename it. Add -disabled to the end, something like mytheme-disabled.
WordPress can't load a theme from a folder that doesn't exist anymore. It falls back to the latest default theme it can find, typically Twenty Twenty-Four or Twenty Twenty-Three.
If no default theme is installed, you'll need to upload one manually. Download it from WordPress.org, unzip it, and upload the folder to /wp-content/themes/ via FTP.
When the Theme Is the Problem
Patchstack found that 4% of all WordPress vulnerabilities in 2024 came from themes, accounting for 326 separate issues. That's a smaller slice than plugins, but it still adds up to real problems on real sites.
Custom themes from marketplaces like ThemeForest are the usual suspects. They often bundle built-in booking engines, custom page builders, and role-management code that conflicts with WordPress core permission checks.
If switching to a default theme fixes your access, you have a decision:
- Update the theme if a newer version exists
- Contact the theme developer with the exact error and your WordPress version
- Move to a more stable theme that doesn't override core permissions
Themes like Astra, Hello Elementor, and GeneratePress are designed as lightweight foundations. They rarely cause permission conflicts because they don't try to manage user capabilities.
Building a site on a solid theme is a lot like following good web design principles. Start with a clean structure and layer functionality through tested plugins, not through bloated theme code.
Reset File Permissions on the Server
Wrong file permissions rarely cause this exact error by themselves. But they can make it worse, or prevent other fixes from working.
If WordPress can't read the files it needs to check your role data, the permission check fails. And you get the same "not allowed" message.
Correct WordPress File Permissions
The WordPress developer handbook is clear on this:
| Item | Permission | What It Means |
|---|---|---|
| Directories | 755 | Owner: read/write/execute. Others: read/execute |
| Files | 644 | Owner: read/write. Others: read only |
| wp-config.php | 440 or 400 | Owner: read only. Others: no access |
Never set anything to 777. That gives every user on the server full read, write, and execute access. It's a massive security hole. Patchstack notes that many hacked sites they clean had 777 permissions somewhere in the directory.
How to Reset Permissions
Via SSH (if your host provides access):
find /path/to/wordpress -type d -exec chmod 755 {} ; find /path/to/wordpress -type f -exec chmod 644 {} ;
Then set wp-config.php separately to 440.
Via FTP: Select all files and directories in your WordPress root. Right-click, choose "File Permissions." Set 755 for directories (apply recursively to directories only), then 644 for files (apply recursively to files only).
Some managed hosts like SiteGround and Bluehost offer a "Fix Permissions" tool in their control panel. Check before doing it manually.
Repair and Optimize the WordPress Database
Corrupted database tables can silently break authentication. If the wp_usermeta or wp_options table is damaged, WordPress may not be able to read your role data even when the values are correct.
Using the Built-in Repair Tool
WordPress has a database repair tool, but it's turned off by default. To enable it, add this line to your wp-config.php file:
define('WP_ALLOW_REPAIR', true);
Then visit https://yourdomain.com/wp-admin/maint/repair.php in your browser. No login required (which is exactly why you need to remove this line after you're done).
You'll see two options: Repair Database and Repair and Optimize Database. The second one is slower but more thorough.
Repairing Through phpMyAdmin
Open phpMyAdmin and select your WordPress database. Check the boxes next to wp_usermeta and wp_options (these are the two tables most relevant to this error).
From the dropdown at the bottom, select "Repair table." phpMyAdmin will fix any structural damage.
The average cost of a data breach reached $4.88 million in 2024, according to IBM. A corrupted database table might not seem like a security issue, but if it forces you to lower your security posture (like adding repair constants or granting broader access) while troubleshooting, you're creating openings.
WP-CLI Method
If you have SSH access and WP-CLI installed, one command handles everything:
wp db repair
Clean. Fast. No need to edit wp-config.php or open a browser. WP-CLI is one of those tools that's worth learning for any WordPress admin who manages more than one or two sites.
Don't forget: If you added the WP_ALLOW_REPAIR constant, remove it from wp-config.php once you're done. Leaving it in means anyone can access the repair tool without logging in.
Create a New Admin User Manually
Sometimes the existing admin account is beyond repair. The usermeta is corrupted in a way that editing won't fix, or a security plugin has blacklisted the user ID. When nothing else works, creating a fresh administrator account bypasses the problem entirely.
SQL Query to Insert a New Admin User
Open phpMyAdmin and select the SQL tab. Run this query (replace the placeholder values with your own):
INSERT INTO wp_users (user_login, user_pass, user_nicename, user_email, user_status) VALUES ('newadmin', MD5('yourpassword'), 'newadmin', '[email protected]', '0');
Note your new user's ID from the wp_users table. Then insert the role data:
INSERT INTO wp_usermeta (user_id, meta_key, meta_value) VALUES (NEW_ID, 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}');
INSERT INTO wp_usermeta (user_id, meta_key, meta_value) VALUES (NEW_ID, 'wp_user_level', '10');
Replace NEW_ID with the actual user ID.
Change the password immediately after logging in. MD5 hashing alone is weak. Once you're in the dashboard, WordPress will rehash your password with its stronger default method (phpass).
Alternative: WP-CLI and functions.php Methods
WP-CLI: If you have SSH access, this single command creates a new admin:
wp user create newadmin [email protected] --role=administrator --user_pass=yourpassword
functions.php method: Add this temporary snippet to your active theme's functions.php via FTP:
add_action('init', function() { if (!username_exists('newadmin')) { $user_id = wp_create_user('newadmin', 'yourpassword', '[email protected]'); $user = new WP_User($user_id); $user->set_role('administrator'); } });
Visit your site once (even the front end) to trigger the function. Then delete the snippet immediately. Leaving it in functions.php means every page load checks for and potentially recreates that user.
Security here matters. Wordfence data shows that 8% of hacked WordPress sites were compromised through weak passwords. Don't use "admin123" as your temporary password, even for five minutes.
Multisite-Specific Fixes
WordPress Multisite has its own permissions layer on top of everything discussed above. The "not allowed to access this page" error is more common on Multisite because the role system is stricter.
Super Admin vs. Administrator
On a regular WordPress installation, Administrator is the highest role. On Multisite, it's not.
Super Admin controls the entire network. They can install plugins and themes, create and delete sites, and manage all users across every site in the network.
A regular Administrator on a Multisite subsite has reduced capabilities. They can't install plugins, can't edit user profiles on their own site (in some configurations), and can't access network-level settings.
| Capability | Super Admin | Subsite Admin |
|---|---|---|
| Install plugins/themes | Yes | No |
| Manage network settings | Yes | No |
| Edit users across sites | Yes | No |
| Manage site content | Yes | Yes |
If you're an Administrator on a subsite trying to access a network-level page, you'll get the error. That's not a bug. That's how Multisite works.
Granting Super Admin Through the Database
Locked out of the network dashboard completely? You can grant Super Admin status through MySQL.
Open phpMyAdmin and go to the wp_sitemeta table. Find the row where meta_key is site_admins.
The value is a serialized PHP array listing usernames of all Super Admins. It looks something like a:1:{i:0;s:5:"admin";}.
To add yourself, you need to update the serialized string. If you're adding "newadmin" (8 characters) to an array that already has one entry, the new value would be:
a:2:{i:0;s:5:"admin";i:1;s:8:"newadmin";}
Get the string length right. The number after s: must match the exact character count of the username. One wrong digit and WordPress ignores the whole array.
Network-Activated Plugins Blocking Access
Plugins activated at the network level affect every site. If a network-activated security plugin blocks access, individual site admins can't deactivate it from their dashboard.
The fix is the same FTP approach from earlier. Rename the plugin's folder in /wp-content/plugins/ to disable it. But on Multisite, this affects every site in the network, not just one.
WordPress Multisite serves organizations running over 140,000 school websites and major institutional networks. The permission errors on these setups tend to cascade. One misconfigured network plugin can lock out hundreds of site administrators simultaneously.
If you're managing a Multisite network professionally, proper configuration is one of those website checklist items that should be verified after every major update. One missed constant in wp-config.php, one wrong serialized value in wp_sitemeta, and the whole network goes sideways.
FAQ on How To Fix Sorry You Are Not Allowed To Access This Page
What causes the "sorry you are not allowed to access this page" error in WordPress?
This error triggers when WordPress checks your user role permissions and finds you don't have the required capability for that page. Common causes include corrupted wp_usermeta data, a plugin conflict, a database table prefix mismatch, or wrong URL settings in wp_options.
Can a plugin cause this WordPress admin access error?
Yes. Security plugins like Wordfence or iThemes Security frequently modify user capabilities. Membership plugins and caching plugins can also trigger it. Disable plugins via FTP by renaming the plugins folder to isolate the conflict.
How do I fix this error if I can't access wp-admin at all?
Use FTP or your hosting file manager to access your site files directly. You can also edit the MySQL database through phpMyAdmin in cPanel or Plesk. Both methods bypass the WordPress dashboard entirely.
How do I check my user role in the database?
Open phpMyAdmin, find the wp_usermeta table, and search for your user ID. Check that wp_capabilities shows a:1:{s:13:"administrator";b:1;} and wp_user_level shows 10. Edit them if they're wrong.
Does this error happen after WordPress migrations?
Frequently. Migrations often break the siteurl and home values in wp_options, or create a mismatch between the table prefix in wp-config.php and the actual database tables. Both scenarios lock you out of the admin dashboard.
Is this error the same as a 403 Forbidden error?
No. A 403 Forbidden comes from your web server (Apache or Nginx) and blocks access at the server level. The "not allowed to access this page" error is a WordPress application-level block based on user role permissions. Different causes, different fixes.
Can a theme cause this permission error?
Yes. Custom themes with role-manipulation code in functions.php can override WordPress permission checks. Switch to a default theme like Twenty Twenty-Four via FTP to test. If access returns, the theme was the problem.
How do I create a new admin user if my account is corrupted?
Run an SQL INSERT query in phpMyAdmin to add a new user to wp_users, then add the administrator role in wp_usermeta. You can also use WP-CLI with the wp user create command if you have SSH access.
Why does this error appear on WordPress Multisite?
Multisite distinguishes between Super Admin and regular Administrator. Subsite admins can't access network-level pages. If you need full access, your username must be listed in the site_admins value inside the wp_sitemeta table.
Will resetting file permissions fix this error?
By itself, probably not. But wrong permissions can prevent WordPress from reading your role data correctly. Set directories to 755, files to 644, and wp-config.php to 440. Then check your user role in the database separately.
Conclusion
Knowing how to fix "sorry, you are not allowed to access this page" comes down to checking a few specific things in the right order. Start with your wp_capabilities value in the database. Then verify your site URL settings, table prefix, and plugin list.
Most of the time, the fix takes less than ten minutes once you've identified the cause. A corrupted role in phpMyAdmin, a stale cache from a security plugin, a bad migration that broke your wp_options values. These are all reversible.
If the standard fixes don't work, create a fresh administrator account through MySQL or WP-CLI and start clean.
Keep your WordPress core, themes, and plugins updated. Back up your database before running updates. And test changes on a staging site when possible. These habits prevent most permission errors from happening in the first place.
Bookmark this guide. The next time your WordPress dashboard locks you out, you'll know exactly where to look.
