Issue Summary
When creating a site using a shared folder, there seem to be permissions issues. Some files/folders don’t seem to be readable. I cannot install new plugins or themes. At least the WP Dashboard still works (after a bit of tinkering)!
Troubleshooting Questions
This happens only when we try to install WP in a shared folder. We have mapped the shared folder to drive x:
We can install WP in a default folder, but would prefer to install it on this shared drive.
Replication
- We made sure that Local was working properly by installing WP into the default location.
- We installed WP in a folder on drive x: using Advanced Options and setting the Local site path to x:\test
Local runs through the usual setup progress, Adding WordPress etc.
You can see that it has created three folders in x:\test
app
conf
logs
In the app folder we get a full set of the default WordPress files.
An error appears in Local:
Error: Commain failed: “c:\Program Files(x86)\Local\resources\extraResources\bin\wp-cli\wp-cli.phar” --path=“X:test\app\public” – require=“C:\Program Files(x86)\Local\resources\extraResources\bin\wp-cli\local-wpcli-error-reporting.php” --skip-plugins --skip-themes “core” “config” --skip-check --dbname=local --dbuser=root --debpass=root --skip-salts
Error: It seems, the WordPress core files do not have the proper file permissions.
Then it just hangs and the progress animation in Local says Installing WordPress…
Letting that run for at least 5-10 minutes, nothing happens. So we force quit Local.
Thinking that we could simply use “Properties” in Windows to select the x:\test folder and update permissions, in the Permissions tab we have for Group or user names:
1033 (unix User\1033)
administrators (GIRAFFE\administrators) (where GIRAFFE is another way of referring to our local network server.
JOJO (GIRAFFE\jojo) (where jojo is the username that has connected to drive X:)
We select these users and click Edit and apply Full control, which should solve the problem, one would think.
Then returning to Local, we restart Local, and start the site.
The WordPress standard installer appears when accessing the site in the browser. That is, when going to http://test.local/ it changes the URL to http://test.local/wp-admin/setup-config.php .
Of course at this point we do not know the database user/password or we could attempt to complete the installation. We try using local/root/root/localhost for database name/user/password/host (as that is what appears in the successful default installation’s wp-config.php) and get the error in the browser " Error establishing a database connection".
Looking in X:\test\logs\nginx error.log is empty.
Then we restart the site in Local. Then we get the same WordPress standard installer (setup-config.php) and enter local/root/root/localhost for database name/user/password/host. This time it seems to be more successful but it says: Unable to write to wp-config.php file.
Then we create a wp-config.php file with these settings:
define( ‘DB_NAME’, ‘local’ );
define( ‘DB_USER’, ‘root’ );
define( ‘DB_PASSWORD’, ‘root’ );
define( ‘DB_HOST’, ‘localhost’ );
The next time we go to the url, it seems to be part-way through the installation. It asks for a username/password/email for the admin of the site. It seems like the installation may be complete!
Trying to log in, we see an error immediately above the usual WP admin login:
Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in X:\test\app\public\wp-includes\formatting.php on line 5397
Then, a string of errors atop the WP Dashboard, starting with:
Deprecated: Return type of Requests_Cookie_Jar::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in X:\test\app\public\wp-includes\Requests\Cookie\Jar.php on line 63
Continuing to click around in what seems to be a working WP Dashboard, those errors disappear.
But when going to Appearance:Themes, the twentytwentythree default theme is active but has an error: Error: Stylesheet is not readable.
Basically all of the themes are broken:
twentytwentyone Stylesheet is not readable.
On the plugins page there are none available, and usually a default WP installation includes Akismet or Hello Dolly.
Going to add new plugin, another string of errors appears, starting with:
Deprecated: Return type of Requests_Cookie_Jar::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in X:\test\app\public\wp-includes\Requests\Cookie\Jar.php on line 63
The Classic Editor’s Install or Update button is replaced with a button that says Update failed.
Clicking that button results in this error:
Downloading installation package from https://downloads.wordpress.org/plugin/classic-editor.1.6.2.zip…
The authenticity of classic-editor.1.6.2.zip could not be verified as no signature was found.
Deprecated: http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated in X:\test3\app\public\wp-includes\Requests\Transport\cURL.php on line 345
Trying to install Akismet also fails:
Installation failed: There has been a critical error on this website. Please check your site admin email inbox for instructions.Learn more about troubleshooting WordPress.
Interestingly, when going to look in the wp-content/plugins folder, there is the hello.php file (meaning Hello Dolly is installed but not showing up) and an akismet folder. Inside the wp-cotnent/upgrades folder there are folders for the failed plugin installations: akismet.5.0.2 and class-editor.1.6.2.
So it seems like Local has no trouble creating files, just making them execute is the problem.
Returning again to select the folder wp-content and set permissions in Windows for the users, there is no way to make it have any other settings; all the “Allow” checkboxes are checked and greyed out, and the only thing that could be done would be to “Deny”. Gritting our teeth, we click Deny, thinking that then we can re-apply “Allow” after that is done. But then there is no way to re-Allow afterwards.
Various
System Details
-
Which version of Local is being used? Current
-
What Operating System (OS) and OS version is being used?
Windows 10 -
Attach the Local Log. See this Help Doc for instructions on how to do so:
Security Reminder
Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however there’s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isn’t private info like passwords being displayed.