"Sorry, you are not allowed to access this page."

Support
1

Issue Summary

Unable to access the admin panel for the imported Wordpress site. Result is “Sorry, you are not allowed to access this page.”.

Troubleshooting Questions

Creating a brand new Wordpress site in Local works fine. Admin access works fine on that blank site. However, the one and only production site we have does not allow Admin access after importing the site into Local.

Replication

Production site is copied/exported via WP-Migrate. Imported into Local. Regular access to the site works fine, Admin login works fine, but does not allow access to the Admin panel in Wordpress. Even when ALL plugins have been disabled, and the theme has been reset to TwentyTwentyThree.

Database checks out fine, the user (ID=1, first user created in the original install, with Admin access) has Administrator and Keymaster access in wp_capabilities.

I have read every single posting on this forum listing the same issue (quite a few posts with this!), unfortunately none mention a possible solution or venue to pursue to find the solution.

System Details

Local is version 6.6.1+6281, just installed.

OS is Windows 10 Pro

local-lightning.log (111.5 KB)

Thank you for any help you can give! Local looks like a wonderful tool, and I would very much like to make it work!

-Rob-

2

Hi @Rob

It’s possible that something went wrong with the import. Do you have any antivirus, security, or firewall applications that could be conflicting with Local? This can be a common issue for Windows users.

This article provides a lot of great troubleshooting steps for this specific error as well that may help:

3

Thank you for the fast reply Nick!

No interference from local firewall etc., that would affect overall access to the local site while I have no problem at all accessing Local or the site. It’s just the Admin login that’s affected.

I’ve seen a link to that how-to-fix article in another (similar) post, went through it in detail already to no avail. Nor was there a fix posted in the thread that mentioned a similar problem.

Listen, I get that it’s something to do with Wordpress in my particular site that I’m trying to run on Local. However, the site runs fine on our Linux server. It’s some type of interaction between Local and the site (most likely the database since the rest is down to plain Wordpress with a plain/default theme). There are enough posts on this forum with the exact same issue that I would hope the Local Team is willing to look into this and once and for all figure what’s causing this. I’m willing to help any way I can. If you want a copy of our site, contact me directly (you should have access to my E-mail) and we’ll get that done.

Local seems to be a GREAT environment to debug sites on, that’s what I installed it for, PHP debugging. We just need to get it to work with real-world sites…

-Rob-

4

Hi @Rob

In the logs I’m seeing this:

\nERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)\r\n\n

Usually, that’s any indication that a security feature or something else may be blocking Local.

Are you able to create a new site and choose MySQL as the database engine from the “Custom Environment” tab when creating a new site?

Are you able to test loading it on another machine or have a peer do it on their end to see if the behavior is the same?

5

Thanks Nick! Found that in the log once you pointed it out: This is related to MariaDB, seems Local is trying to log in as root to that. I’ll chase that down.

WP clearly has access to the database, or it wouldn’t be rendering the Web site at all, and the WP admin account shouldn’t be related to root access to the database. So I’m not quite (yet) seeing what the one would have to do with the other. I’ll dive into MariaDB access though.

-Rob-

6

Nick, starting the site in Local, opening a browser without logging in, logging in as Admin (and getting the “not allowed access” message); none of that generates a log entry where Local tries to log into MariaDB as ‘root’. I thought it might be Adminer access, as that may require root access, but that works fine too. These are all of lines generated in the Local log (from startup of the site):

{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:50 0 [Note] %%resourcesPath%%\\lightning-services\\mariadb-10.4.10+4\\bin\\win32\\bin\\mysqld.exe (mysqld 10.4.10-MariaDB) starting as process 6216 ...","timestamp":"2023-03-02T12:56:50.965Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"InnoDB: using atomic writes.","timestamp":"2023-03-02T12:56:50.978Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:50 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions","timestamp":"2023-03-02T12:56:50.979Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:50 0 [Note] InnoDB: Uses event mutexes","timestamp":"2023-03-02T12:56:50.980Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:50 0 [Note] InnoDB: Compressed tables use zlib 1.2.11","timestamp":"2023-03-02T12:56:50.980Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:50 0 [Note] InnoDB: Number of pools: 1","timestamp":"2023-03-02T12:56:50.980Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:50 0 [Note] InnoDB: Using SSE2 crc32 instructions","timestamp":"2023-03-02T12:56:50.980Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:50 0 [Note] InnoDB: Initializing buffer pool, total size = 32M, instances = 1, chunk size = 32M","timestamp":"2023-03-02T12:56:50.981Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:50 0 [Note] InnoDB: Completed initialization of buffer pool","timestamp":"2023-03-02T12:56:50.982Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:50 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=667921723","timestamp":"2023-03-02T12:56:50.994Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] InnoDB: 128 out of 128 rollback segments are active.","timestamp":"2023-03-02T12:56:51.169Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] InnoDB: Removed temporary tablespace data file: \"ibtmp1\"","timestamp":"2023-03-02T12:56:51.170Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] InnoDB: Creating shared tablespace for temporary tables","timestamp":"2023-03-02T12:56:51.170Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] InnoDB: Setting file '.\\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...","timestamp":"2023-03-02T12:56:51.170Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] InnoDB: File '.\\ibtmp1' size is now 12 MB.","timestamp":"2023-03-02T12:56:51.170Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] InnoDB: 10.4.10 started; log sequence number 667921732; transaction id 68443","timestamp":"2023-03-02T12:56:51.171Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] InnoDB: Loading buffer pool(s) from %%userDataPath%%\\run\\GlrSXudap\\mariadb\\data\\ib_buffer_pool","timestamp":"2023-03-02T12:56:51.172Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] Plugin 'FEEDBACK' is disabled.","timestamp":"2023-03-02T12:56:51.172Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] Server socket created on IP: '127.0.0.1'.","timestamp":"2023-03-02T12:56:51.177Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] InnoDB: Buffer pool(s) load completed at 230302  7:56:51","timestamp":"2023-03-02T12:56:51.185Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] Reading of all Master_info entries succeeded","timestamp":"2023-03-02T12:56:51.200Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] Added new Master_info '' to hash table","timestamp":"2023-03-02T12:56:51.200Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-03-02  7:56:51 0 [Note] %%resourcesPath%%\\lightning-services\\mariadb-10.4.10+4\\bin\\win32\\bin\\mysqld.exe: ready for connections.","timestamp":"2023-03-02T12:56:51.201Z"}
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"Version: '10.4.10-MariaDB'  socket: ''  port: 10005  mariadb.org binary distribution","timestamp":"2023-03-02T12:56:51.201Z"}

Not a whole lot there, and all looking good.
Continuing the search…

-Rob-

7

Hey @Rob

As a test have you tried creating a new admin user via CLI? If not, could you give that a go and see if that works? Our dev team is wondering if something in the user record is getting corrupted upon import.

For this all you’ll need to do is click on Open Site Shell and then run a command like this: wp user create newusername newusername@example.com --role=administrator. That should kick out a password for the new user that you can attempt to log in with.

8

What do you know, that works! Created a new admin user via the CLI, logged in, and it went straight to the Admin panel. That is bizarre…

I’m happy, but at the same time, what’s going on with the existing user accounts? I’ve imported the site a number of times into Local, including without any themes or plugins, just the database, and it reacted the same each time: The existing Admin account logs in without any error, but the Admin page doesn’t display, as mentioned.

The database entry for the regular Admin account looked OK. Showing administrator rights in there etc. Also, if the import goes wrong it would/should have much more profound effects on the site, as everything comes out of that database, all pages, etc.

Well, we have a work-around now, though this is still a head-scratcher…

-Rob-

9

Hi @Rob! Sending you a DM for further follow up. Thank you :slight_smile:

10

Nick, just to follow up so others reading this thread know what’s happening: I’ve sent an E-mail with a link to a zip-file containing our site so you guys can test locally. Hopefully you’ll figure out why the Admin login is not working!

Thanks again for being so proactive in solving this! Much appreciated!

-Rob-

1 Like
11

Hi @Rob! Received your information and will review it with the dev team. One question and apologies if you’ve mentioned it somewhere but is this or has it ever been a multisite?

12

No, this has always been just a single site.
Thanks Nick!

-Rob-

2 Likes
13

Not sure if this is related, but…

Imported a site into Local. Same problem: “Sorry, you are not allowed to access this page.”.

So I did the CLI dance to add a new administrator-role user. Fine, could log in as that user… but my existing users had no roles! What’s more, trying to edit the roles of the existing users to Administrator DIDN’T WORK. Remained no roles.

So I opened Adminer and had a look at the database, and saw something interesting: on the live hosting site, the table prefix is: ABUb2RM

Imported, the table prefix is: abub2rm

My new user has, in the usermeta table, an entry for “abub2rm_capabilities” but my existing users have “ABUb2RM_capabilities” (note the case). Once I edited the meta_key fields for my existing users and made them all lowercase (matching the case of the imported prefix), BANG - works.

1 Like
14

JMJ, you’re absolutely right!
My own site uses a random prefix for the dB tables, to make hacking a little harder, with several upper and lower case characters. The dB in Local has all lowercase. I can see that would mess up the works bigtime! I’ve checked the exported .sql file from WP-Migrate, it has the correct case preserved in there, so it seems Local is erroneously converting everything to lower case.

Nick, are we on the right track? Should be easy to fix in Local…

-Rob-

15

The Cross-Platform Follies! Takes me back to my days as a grad student and TA: doing my stuff on Unix, while teaching the students on WinTel (Windows and MS-DOS then). Not only was there the difference in case sensitivity, the path separator slash direction - “/” versus “” - drove you bonkers. (And those were for openers…)

16

Thanks, @jmj and @Rob for your further insight! I’ve shared your observations with the Local team to assess and we’ll keep you updated!

17

Hi Nick, any progress in coming out with an update that preserves the case of database tables (as opposed to converting everything to lower-case as it does now)? I believe that would solve this issue.

Thanks!

-Rob-

19

Hi @Rob

I checked with the team and this is still on their radar! No ETA yet as they have to prioritize some other items but as soon as we have news to share we’ll update this thread.

20

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.