"Sorry you are not allowed to access this page." when saving settings in the admincp

[llewen]

What is happening is when I try to make a change to the Components section in BuddyPress settings, I get the infamous “Sorry, you are not allowed to access this page.” when I try to save the settings and the settings do not take effect.

I am able to successfully enable and disable settings on the Options tab.

I have followed all the steps on several sites that talk about sorting this error, including reinstalling WordPress, deactivating all plugins, enabling debugging, using the default theme, regenerating permalinks, etc. etc.

The account has administrator role, and bbp_keymaster capabilities, from my attempt to fix the problem by installing bbPress. Deleting the database and starting over is not an option, even though this is a new site, I already have content.

What is odd is, when I get the error in WordPress, there are no corresponding PHP or Apache errors, and when I enable debugging, no errors are logged.

The only explanation I can come up with is that I have enabled IPv6/dual stack support on my network and it appears that the connection IP from my account isn’t consistent. Sometimes it connects with the IPv4 address, sometimes with the IPv6 address. That’s the only odd thing I can see in the Apache logs.

Site URL: ​https://displaced.zone

WordPress Version: 5.8.1
Directory install in root directory
Upgraded from WordPress 5.7.1
WordPress functions properly, other than this one problem
BuddyPress Version: 9.1.1
Not upgraded from a previous version
Other Plugins: BP Better Messages, Comments Like Dislike, Top Bar, WP Cerber Security, WP Mail SMTP
Theme: NS Minimal with minor css tweaks
Core files have not been modified in any way
No custom functions
bbPress not installed, although I did install it to see if it would fix the problem
No server error logs, which is weird
Self hosted on a home network. I’m not a novice at this, I have done this for years, including a previous WordPress website where I had BuddyPress installed in the same environment, and did not have this issue. The only thing that has changed is the IPv6 support.
Server OS: Debian GNU/Linux, Bullseye, typical LAMP stack
I have tried both the Legacy and Nouveau BuddyPress themes
I have made no changes to BuddyPress template files
The only other information that might have a bearing on this is that I am not running WordPress “The Debian Way”. I have copied all the files, including the symlinked php libraries, out of the Debian file structure and am running them out of a folder in my home directory. Apache is running as that group and user. But again, I have done this for an entire year, successfully, with another website. Running WordPress this way allows me to use the built in WordPress update system, which doesn’t function as expected if you run WordPress “The Debian Way”.

I should add to this that I get the same error whether I connect with the IPv4 or the IPv6 address.

Other things I’ve tried to fix this:

disabling ModSecurity
disabling PHP and Apache caching

PHP version is 7.4.

So now I’ve completely nuked the database, deleted the installation, reinstalled from official download tar.gz except for the .htaccess and wp-config.php. The only plugin installed and active is BuddyPress, and I am still having the same problem.

I’m now going through php.ini to see if there is anything there that might be causing this.

It’s also worth noting that the WordPress health screen shows no problems. So I’m stumped.

[llewen]

Disabling IPv6 did not solve the issue. So I have no idea whatsoever.

[llewen]

I was finally able to enable components from the inactive components menu...

[imath]

Awesome, thanks a lot for your update. I must confess I wasn't sure how we could address this issue. I'm closing the ticket. Don't hesitate to reopen it if needed.

[llewen]

I'm not reopening this. I just wanted to say, I have had this problem with other plugins and other menus in WordPress. I think this is a bug with a core WordPress function, I just have no idea which one it is. I had just never had the problem in a context where it was either a plugin that was essential to the function of my website, or where I couldn't find a work around.

And in this case I did eventually find a work around, it just took me a while...

But yes, I think there's a core WordPress function that is broken in some way. I just have no idea what it is, or where or how to submit a bug report about it.

[imath]

To report a bug about WordPress, it's this place ​https://core.trac.wordpress.org/newticket but before doing so and to be efficient so that a WordPress contributor can fix it, I'd advise you to find how to reproduce it for sure and then describe the steps to get the issue.

[llewen]

I've worked on software myself, and I know how difficult it is to deal with bugs that can't be reproduced. Unfortunately I don't have any idea what is causing the bug or how to reproduce it. Obviously it's something particular to my setup, or there would be a lot more posts and reports about it.

If I ever find a way to faithfully reproduce it, I will submit a bug report. Thanks.

[llewen]

I finally figured this out. I've had a number of problems with the WordPress admincp and getting the infamous "Sorry, you are not allowed..." error. And it was obviously my problem because no one else was reporting the error. I've been banging my head against the wall on this one for a year and a half now.

Turns out I was too smart for my own good. I use modsecurity, I absolutely love modsecurity and wouldn't run a server without it. However, one of the "features" of modsecurity allows you to change the server signature, and I had changed it to "Microsoft IIS 5.0", one of the most hackable pieces of web server software in the history of computing as a joke on would be hackers.

What I didn't realize is that the "$is_apache" variable in WordPress uses that server signature to determine what server software you are running, and various bits of WordPress use that variable to change behaviour in significant ways. For some reason modsecurity changed that server signature permanently, so even if you disabled modsecurity entirely, it would still show the server signature as whatever you changed it to.

So, yes, I love modsecurity, but there are things that it can do that can make a mess if you don't know what you are doing. The takeaway is, don't mess with the server signature, even if you think it might be funny to do so...

[imath]

Hi @llewen

Thanks a lot for your update. I'll keep it in mind 😉

[llewen]

Trust me to find some really weird way of breaking the interwebs...