WordPress Error: You do not have sufficient permissions to access this page

Were you just locked out of your WordPress blog’s administration area? When you try to access the admin area, do you see the error message, “You do not have sufficient permissions to access this page”? Did you just recently run a prefix changer to tighten the security of your blog?

If the answer to all of these questions is “yes”, then this may be the solution that you are looking for. We have seen this error message for a few different issues, such as with an old, outdated plugin that is no longer compatible with a new version of WordPress, but for that problem the message only displays when you try to access the plugin’s setup page. The issue that we are describing locks a blog owner out of the entire admin area. The only thing that displays on the screen is the error message.

We have seen this twice after we hardened a blog against attacks by changing the table prefix using the prefix changer built into WP Security Scan. After digging into this issue, we discovered that the root of the problem is due to an apparent bug that does not change all of the database table name references in the wp_usermeta table. While all of the table names do get changed, one or more of the references to the new table names is skipped.

If you run into this problem, use the phpMyAdmin utility or whichever database management utility your hosting company provides in your site’s control panel to access the wp_user_meta table.

1. Open the WordPress database.

2. Make a backup of the database, just in case something gets screwed up. An easy way to create a quick emergency backup within phpMyAdmin is to select a database, click on the Operations tab and use the “Copy database to” utility to make a copy of your database under a different database name. Make sure that “Structure and data”, “CREATE DATABASE before copying” and “Add AUTO_INCREMENT value” are all selected. Enter a name for the copy of the database. If you do run into a problem, you can simply change the database name in wp-config.php to switch to the copy of the database. Another good idea when working with a small table is to print out a screen shot that shows all of the values and data as they existed before you make any changes.

3. Select the user_meta table. Because you just changed the table prefixes, the “wp_” prefix on the user_meta table name will reflect the new prefix. Just look for a table that uses the new prefix along with “usermeta”.

4. Use the browse tab and scan through the meta_key column and look for any references to the old table names. I usually find the following six, but there could be more or less, depending upon which version of WordPress you are using and how your have your admin users configured. There are not very many rows in this table, so it is easy to scan. If you have more than one user account set up, your will find that some of these columns are duplicated for each user.


You do not have sufficient permissions to access this page

For the WordPress blog that we were working with in the example show above, two users (see user_id column) were configured. The critical data field that was causing the error for us and preventing us from logging in was wp_capabilites, which sets the user level for each admin user. We changed both instances of wp_capabilites in the meta_key column to wp_qs1_capabilities and we could then log in once again.

As shown above, the wp_usersettings and wp_usersettingstime values had also not been changed by the WP Security Scan prefix changer. However, after simply changing wp_capabilites, we logged in and found that WordPress had automatically created new rows for these values using the new prefix. It looks like other values that could be important include wp_user_level and wp_autosave_draft_ids. If you are still experiencing unusual behavior with the admin section after changing the wp_capabilites value, it is possible that the other two values also need to be changed to reflect the new prefix.

It may not be necessary to change every instance of the old table prefix in the meta_key column because it appears that WordPress will create some of these as needed. If you do change other meta key values, just be careful that you are not duplicating a row that already exists. The important part is that only one of each meta key value should exist for each user (user_id). You will find that some users have meta_key references assigned that do not exist for other users. That should be okay because some of these reference keys are created only as they are needed.


  1. Axel says

    Thanks for your article, it has helped me.
    To recover my access i had to change all the “wp_” to the new prefix, in all the values of the databases. I had also another one in the wp_options table with the value wp_user_roles.

  2. Cole says

    PHEW! I tried to log in and had the same issue. I manually upgraded but it didn’t help. I added a new user in my DB but that didn’t help because I was using the wrong prefix–how silly of me. Even after I made these changes, I had trouble because I had to change the user roles in wp_options, as Axel said. Wish I’d read his comment sooner. Thanks so much both of you!

  3. Jon Griffith says

    Welp, thanks! That’s exactly what was wrong. My site was with another hosting provider and my database prefix used to be active_wp_etc because I only had one MySQL database for multiple blogs. Now that I have a schema for each blog, I was able to default to wp_etc as the table prefix…but when I restored the data, it brought with it the wrong data.

    I had even scanned the SQL statement for active_ with a “find and replace” but must have missed a few.

    Either way, it was those 6 in the wp_user_meta AS WELL AS one in the wp_options table. Thanks!

  4. Marc says

    WordPress Insufficient Permissions Solved!!
    I too had changed all my wp_ prefixed tables. Using Navicat, I:
    – loaded my new ??_usermeta table and sorted the metakey column to locate all the wp_ values easily.
    – changed all the wp_ to my new prefix.
    – loaded my new ??_options table, located wp_user_roles and changed the prefix there too.
    It works perfectly.
    Thanks a load Jonathan for the article, and to you Axel for your contribution.

  5. michael says

    thank you thank you thank you thank you thank you thank you thank you
    thank you thank you thank you thank you thank you thank you thank you
    thank you thank you thank you thank you thank you thank you thank you
    thank you thank you thank you thank you thank you thank you thank you

    all i had to do was change the one prefix on wp_capabilities and BAM i could once again administer my own site.

    i have no idea what i am doing, but i can follow directions and it worked.

  6. Don says

    Thanks for this super-helpful post. It quickly got me on track to restore my site!

    I did find one thing not mentioned above that may be of use to other visitors…
    In the table usually called wp_options (but which will obviously have a different prefix per the WordPress hardening scenario) I had to locate an option_name wp_user_roles and give it the new prefix I had applied to my WP tables. It is a big table, and for me the row I needed to find was record number 95 …so be aware it is a multiple-screen table if you need to look for it.

    At this point the site seemes to be OK. This table wp_options seems to have a couple of other option_value settings that have the old wp_ prefix and I have not changed them since the site seems OK.

    They are:

    sidebars_widgets with a reference to “wp_inactive_widgets”
    and cron with a reference to “wp_version_check”

    Hope this additional info proves useful to someone! Again, many thanks! Excellent post!

  7. Adia says


    I needed a step-by-step guide, and this was great. I’d changed my table prefixes and then couldn’t log in. No one else clarified the problem quite like you did.

    THANK YOU, again.

  8. Stanislav says

    I have encountered this problem when I activated the plugin “Multiply”
    The problem disappeared after I removed the plugin.

  9. YourCustomBlog says

    Worked for me — had to change two entries:

    wp_capabilities — meta_key in user_meta


    wp_user_roles in wp_options


  10. Robert Pulson says

    Thanks for the post. This pointed me in the right direction to get my administrative access back.

  11. Dan says

    Well, this didn’t work. I’m on Rackspace Cloud Sites. Anyone else having this problem on Rackspace?

  12. Deron says

    Awesome thanks for this post! I installed using cpanel, and there must be a bug with cpanel that does not update all those settings when you change the DB prefix.

    Thanks again!

  13. Mike says

    Many thanks for this. It fixed the problem I had when I moved from one server to another.

  14. Chris says

    Did not work for me. All entries in _usermeta are on the new prefix. Still does not work.

  15. Julia says

    Thank you so much! Mine was in the wp_options–>wp_user_roles. You saved the day!

  16. Steve C. says

    Wow, that was timely and effective — though I had the opposite issue: double-prefix! So, in my case it was:

    _dev_dev (instead of simply _dev).

    Thanks a ton!


  1. […] Written by Graziano on gennaio 19th, 2011. Posted in Blog Sono cascato in questo problema e ho trovato la soluzione. Dopo una installazione nuova non riuscivo in nessun modo a entrare nell’area Admin di WordPress, dopo che inserivo user e password ottenevo l’errore Non si dispone di permessi sufficienti per accedere a questa pagina Ho trovato la soluzione in questo articolo in Inglese “You do not have sufficient permissions to access this page” […]