Hey guys, I have been spending the longest time trying to figure out this issue. I would like to know what the file permissions should look like in WordPress in order to use the autoupdate feature. As of now, my wordpress installation keeps asking me for my FTP information and I do not want to use that method of upgrading/installing, I want to use pure/direct PHP.
Some context:
- webserver and php fcgi daemons run as
www-data:www-data - wordpress installation is at
/home/blaenk/sites/domain.tld/
At first, I read that all files/folders should be owned by my user (blaenk) and writable by my user. But this wasn’t working, after spending many hours researching, someone on the IRC channel told me to try setting everything to ownership www-data:www-data and this worked. I was no longer asked for FTP information and the plugin installation worked automatically.
However, I originally placed the site files in my home directory precisely because I wanted to be able to write/create them as my user. I even added myself to the www-data directory as stated in this guide.
Question
I already know that files should be 644 and directories should be 755. However, this seems more of an issue of ownership. I don’t want to have to set www-data:www-data on everything in my wordpress installation, so I’m wondering what files/directories specifically require this ownership level?
EDIT: I believe that the reason for which everything seems to work on my shared hosting wordpress installation despite all of the files being owned by my user is that the shared host I use seems to use suexec which presumably runs PHP as me, so in other words, the files are owned by the webserver, so to speak.
As far as I understand it is not related to specific permissions – Auto Update overall requires that files owner matches user Apache runs under. If that is not the case it falls back to other filesystem methods (FTP, SSH) and so prompts for password.
You can define credentials in constants in
wp-config.phpso you don’t get prompted for them.See WordPress Upgrade Constants in Codex.
In my question, I stated confusion at the fact that everything worked seamlessly on my shared-hosted despite all of the files being owned by my user, whereas on my VPS, the auto upgrade would not work unless all files were owned by the webserver.
I am fairly certain that this is a result of my shared host using suexec which essentially runs the scripts as my user. So essentially, the files on my shared host were owned by the ‘web server’ (really, the CGI daemon).
I am actually running nginx and php-fpm on my VPS, so I do not have access to Apache’s suexec. However, I simply configured php-fpm to run as myself, to test my theory, and it did indeed worked seamlessly with all of the files owned by my user. I believe this would be considered a security risk (not sure), so I will investigate further to see what I can do in this regard to avoid running it as my user, but at least now I know what the problem is!
Assuming you have ssh access, get the “user” first. Often the webserver runs as
www-databut if you’re not sure, runtopand you can see the “USER” of php, nginx, etc.This step is obvious, but find where your files are. Usually your files are under
/home/www-data/but I’ve noticed nginx will default to some other directory that I can’t remember at the moment. In any case,cdto the directory that holds all your domains.chown -R www-data:www-data example.comThis recursively changes the ownership of all the files under the example.com directory. Most likely this won’t break anything.Usually the files are already set to the correct permission, but after hosting with dozens of companies I can tell you permissions are occasionally changed by sysadmins by accident, it’s just a fact of life. For example, mounting with sshfs could change the ownership.
Your ‘mixed’ experiences probably come from wether your two users in question are in the same group or not. And of course what âgroup rightsâ happended to be around
Traditionally in php, the phpuser (aka apacheuser or webuser or cgideamon) has no right to change files, which only the ftpuser (aka âyour user accountâ in some codex descriptions) can, to make it harder for security exploits to change scripts.
Which of course makes any php-based update of php files impossible. Thus with PHP in general, it’s common to change file ownership from FTP user to phpuser. Before doing so it’s worth noting, that the ‘updating’ happens in âFTP shoesâ (as you give the credentials). Then unpacking of downloaded zips possibly happens of course again by scripting means… well, and then there’s the wp-content Folder, certainly to be touched and further filled up by means of php scripts… (I guess we all stumbled once about that issue in WP) Things can turn complicated.
in short: WordPress’ Codex has quite a good overview in Hardening File Permissions to be as ‘greedy’/’safe’ with granted file permissions as possible.
By
user accountthey mean FTP account (aka not the cgi deamon/php user/…).