I have installed some Wordpress sites several times using the script in virtualmin. I have done it an overall server user and as the site admin user. no matter what I do, I cannot install plugins or media or amend files via plugins as every time I get one of the following messages:
The plugin has detected that it cannot write to the wp-config.php file. This feature can only be used if the plugin can successfully write to the wp-config.php file.
Unable to create directory wp-content/uploads/2020/03. Is its parent directory writable by the server?
I have checked permissions on the files and folders and they appear to be correct, with 750 at top level directory and then a variety of 750 or 755 for folders at lower level. Files also vary with some at 750, some at 754 and a couple at 644. I read that folders should be 750 and files 644 but if they are higher that should allow greater access not restrict it.
Ownership:Group is also correct as adminname:adminname.
I have validated the server and the server permissions but still I cannot write to the files. In addition, every time I try to install or remove a plugin, I am confronted with an ftp request which I do not have on my other sites (hosted elsewhere).
I have read all I can find on google and in these forums but I still cannot find a solution other than opening all files to 777 which not very sensible.
If I know what the problem was I could fix it but I just cannot find what is preventing the writing to the files. Can anyone help me?
A bit more information. For some reason I can definitely access the databases as it is allowing me to write and publish new pages but it will not let me install a plugin (other than over ftp) nor will it let plugins etc. or the media manager write files to the file structure.
Operating system Debian Linux 8
Webmin version 1.941
Usermin version 1.791
Virtualmin version 6.08
Authentic theme version 19.45
Kernel and CPU Linux 3.16.0-10-amd64 on x86_64
Also, Can’t run and read a log file as the site cannot add one due to permissions problem!
Painstakingly checked all permissions through the file structure (again) and it is OK.
Confirmed that the site admin (xxxxx) is member of www-data group and vice versa.
Not sure it is permissions or ownership. admin and www-data are in each others groups. when I set public_html recursively to 0777 it still does not allow a file to upload or the directory to be created whether I use admin:admin or www-data:www-data as the owner:group.
Are there other logs I should be looking at?
PHP execution mode is FGGId
root@xxxxx:/home/xxxxx/public_html/wp-content/uploads/2020/03# ls -la
total 8
drwxr-x— 2 xorex xorex 4096 Mar 16 01:40 .
drwxr-x— 3 xorex xorex 4096 Mar 16 01:40 …
root@xxxxx:/home/xxxxx/public_html/wp-content/uploads/2020/03# ls - returns no files or directories.
I am wondering if it is a PHP issue. I haver my server template PHP set to highest available (7.3.15) but php -v tells me 7.2.28.
I have checked website options which show various php installations including 7.3 but I notice that 7.3 does not have module mysql installed. When I do a health. check on the Wordpress site I get an error that says I am running php 7.0.33 on Debian 8 when I have upgraded to Debian 9!
I have deleted the script instance and reinstalled it but it is the same.
I have sorted the PHP issues and php -v now gives:
PHP 7.3.15-4+0~20200224.55+debian9~1.gbpbea824
However, the Wordpress site now says:
PHP version 7.0.33-25+0~20200225.32+debian9~1.gbpa11893 (Supports 64bit values)
it is now recognising Debian 9 but still not selecting the right php version. I have rebuilt the virtual server and the Wordpress site after sorting the PHP issues so do not understand where it is getting the php version error from.
I ran into the same problem and tried chown and other tactics.
The successful strategy that worked for me to avoid the dreaded inability to download themes and plugins or upgrade Wordpress was to insert the direct FS_METHOD into wp-config.php:
I looked but that only activates a bypass for ftp. I found a solution that started to work. It recommended setting the ownership as www-data:admin and it did begin to write to the folders. However when it did it changed ownership to www-data:www-data which is weird because when I set ownership to www-data:www-data before it did not work.
I now have a mix of www-data:admin and wwwdat:www-data and I am leaving them alone as it is working!
I would still like to know what is causing it. It is a hassle to change ownership on an automatically built site.
Can anyone suggest what I can delve into to try to find what is going on. I know I have logs but not sure which I should be looking at or how to interpret them.
When I interrogate my other sites hosted at Bluehost, ownership is generally admin:admin which is what I would expect to see and those sites all work perfectly so what is virtualmin or the Wordpress script doing to upset this model?
Occasionally it is admin:nobody but this is also acceptable.
@GeoffatMM hi, you run virutalmin on your server? if so you should just log into server with domain user (no root no www-data or anything else) and upload files there and continue installation process as usual. Remember if you log into server via ssh as root only root will be able to upload files… on virtualmin it works differently… If you need more help you can call me on whassap… I will create group where you dont have to share you mobile number…
Hi Unborn, thanks again for the response. I am using virtualmin to manage my sites on my VPS. When I install a site I log out of my admin role (abc) and log back in as the sites admin user (xxxxx). As xxxxx I run the script and it generates the sites correctly (I think) with permissions of 0750 or 0755 and 0644 One or two special files are different (0700) for ssl etc. Ownership is xxxxx:xxxxx. All of that looks right to me and reflects what I have on my Bluehost sites.
However, it will not let me load media or plugins. It will let me generate new pages though (in the database tables?). It is all rather strange.
I added www-data to group xxxxx and xxxxx to group www-data but that did not make any difference
As I said, I found a solution to use www-data:xxxxx and that works but it then starts to change ownership to www-data:www-data (and still seems to work).
I know what I have done should work but for some reason it is not. Something prevents xxxxx user from writing files in the uploads and plugin directories.
Currently locked out of all sites with a £@@* PHP issue now. Ho hum.
hi geoff,
ownership needs to be the virtual server itself.
so for example, lets say you setuup a virtual server and called it apple, virtualmin will also set the administrative user for that virtual server as apple (most likely) then the persmissions should be apple:apple 755 (folders) and 644 (files).
do not set www-adata as the admin owner of it because this means that the entire www-data or apache group has access to the virtual server which is not what you want! Virtual servers maintain separation by having their own www-data/apache admin user (ie apple) which is in the www-data/apache group but doesnt have access to other admin users users directories in that group.
if you have more problems then the go is to do a teamviewer session with either me or someone else to help sort you out.
I am still trying to resolve my php issues (I accidentally deleted some files). Consequently I cannot do anything on the server at the moment. I have deleted the test website I built and as soon as the php is resolved, I will rebuild it and start again. As you can see from the first post here this is where I started from. However, I have now aligned php between the Vmin server and the apache server so it may have improved the situation.
As soon as I get it done and tested I will post here again.
call me video or normal call.