How to control Permissions in Local


I have a fairly recent installation of Local (PHP 7.2, MySQL 5.6.34, WP 5.2.2) on Windows 10 (fully up to date) and running an old WP website, a copy of an old, well performing live site.

When trying to change a plugin (wp-paginate) CSS settings, I get the following error message:

“You do not have sufficient permissions to edit plugins for this site.”

The plugin support says the error message is coming from WP core, not the plugin itself…

Similarly, when trying to edit the custom CSS file of the theme, which would accomplish the same, my revised CSS code in the theme is properly recorded in the theme CSS files, but it does not get reflected on the pages. Inspecting the CSS elements via Firefox shows that they get overridden by the plugin’s default CSS.

This time, no permission notification is provided.

In other words, attempting to change files on the server somehow gets blocked.

Given that I am the Admin of the site and I have full Admin WP user permissions, it is not WP that’s blocking me.

The LOCAL version of the website is an exact duplicate of a live site, and I never have Permission problems on the live site, so I am assuming it has to do with server permissions, not WP permissions.

How do I change LOCAL permissions?

Thank you,

Help, please…
Thank you,

The plugin support was correct in saying that this is coming form WordPress core. The specific functionality is contained within how WordPress handles permissions. I’d recommend reading more in this developer documentation for WordPress:

As to why the CSS changes that are being made to the custom CSS file aren’t being shown on the main site – that has to do with how CSS handles specificity. You can try to re-write the styles to be more specific, or you could explore dequeuing the plugin’s stylesheet by using the wp_dequeue_style() function:

You mentioned that the Local site is using the latest version of WordPress. Many things have changed with WordPress core over the years, and while WordPress does a great job with backward-compatibility, there’s always the possibility that certain things break with different versions of software.

I suppose it’s possible that Local’s server settings need adjustment, but if that’s the case, then as a dev, I would start to worry about the code quality of the underlying plugin and theme.

Local’s settings work for almost all WordPress sites that I’ve thrown at it. For the ones that did have issues, it was mostly due to how the underlying site was coded, and how inflexible the various settings were in terms of changing environments.

It really depends on what is trying to be changed along with what the overall goal is. Because Local currently uses Docker, many of the notions of permissions aren’t relevant in the WordPress context.

It sounds like many of the recent issues with working with this site involve the older versions of software that are in use. If I were to offer more long-term strategic advice, it would be to take this opportunity to review how much effort would be needed to update the existing software and compare that with the effort needed to re-create the site with a new, more future proof theme, and the minimal amount of up-to-date plugins needed to provide the content needed.

There’s no real right answer, but mostly just the reality of dealing with old software that’s accumulated technical debt.

Hope that helps give some things to think about! Good luck!


Thank you for the extensive reply.

But… In case I wasn’t clear, I’m looking to change the file permissions for the WP setup under Local on the local PC. I know how to do it on a standard server, but not on a Local server. There’s got to be a simple answer to that, no?

And, yes, I realize that even once I change the permissions there might be problems along the possibilities you’ve outlined.

I’m puzzled why you did not include this in your reply.

At the moment, I have a site that is almost there… but not quite. I’m still hoping Local is a good solution for my situation…

Thank you again,

The main reason I didn’t include instructions for this, is that because Local uses containers and mounts the folders of the Host machine into those containers, then any changes to the permissions of those files and folders won’t be reflected within the container.

You could try doing this manually from within the container by right-clicking on the site and selecting “Open Site SSH”. From there, use the terminal to navigate to where you need to try the changes and use the typical Linux command for modifying file permission – chmod.

But again, this shouldn’t be necessary and quite likely it will break things in unusual ways. I don’t recommend doing it.

I still come back to the original error message:

Which isn’t a file permissions thing – it’s part of WordPress’ User Roles and Capabilities.

Have you looked at the actual user roles that are assigned within the database? You can do this by opening “Adminer” from the “Database” tab in Local, and then selecting the data within the wp_usermeta table. You should see a number of entries relating to permissions for each user id:

One other option to rule out, is to create a new admin user using the terminal. To do this:

  1. Right-click on the site and select “Open Site SSH”
  2. Enter in the wp-cli command to create a new user:
wp user create myuser myuser@example.local --role=administrator

This should give you a password to use to try and log into WordPress:

Can you try creating a new admin user and see if that allows you to log into the WordPress admin?