# Recommended File Permissions

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.

• IMHO the question stretches beyond rights, but also onto ownership — the classic ´ftpuser´ and ´wwwuser´, as most apache server (rightfully) have it. There certainly is more than one way to Rome here... So what is the “WP best practice“, the most rigid combination of which (sub)folder to which user with what rights...? – Frank Nocke May 5 '15 at 10:37
• Obviously there are several steps: 1) A file gets downloaded (triggered by the php- aka ´wwwuser´) but rights-wise an ftp operation(?), 2) the file gets unzipped (creation rights for ´wwwuser´), 3) elder files get overwritten (by initial upload quite certainly owned by ftpuser...) ► perhaps turn on very verbose php logging and ('WP_DEBUG', true) of course, to catch all the “moaning“ and shoot them one-by-one? – Frank Nocke May 5 '15 at 10:38

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.php so you don't get prompted for them.

See WordPress Upgrade Constants in Codex.

• Thank you Rarst. I have seen that codex article, however, I absolutely do not want to use FTP/SSH. The reason for this is that somehow, on a shared-hosting site where I installed wordpress manually as well, everything works, even though everything is owned by my own user. Things are owned by my user, but also by another group which I didn't create, so I imagine there is some SETGUID stuff going on here, which is probably how the webserver process is able to run auto update. – Jorge Israel Peña Dec 23 '10 at 9:13
• My guess is your other configuration is using suexec so Apache runs WordPress under your user account and there is no mismatch. – Rarst Dec 23 '10 at 9:21
• Haha, yeah, that's what I said. I'll give it to you since you're the only one that bothered to reply though. Thanks :) – Jorge Israel Peña Dec 23 '10 at 9:29
• Well, it isn't even a hour since your question and there is no really perfect answer - either you make user match or use FTP/SSH. By the way rather than adding solution to your question could you please write it out as an answer with some links on topic and such? So others can benefit from it in the future. – Rarst Dec 23 '10 at 9:34
• No, this is absolutely fine. :) System works to collect and promote great and accurate answers whomever they come from. Multiple answers are good and can highlight different aspects of question. – Rarst Dec 23 '10 at 9:59

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!

1. Assuming you have ssh access, get the "user" first. Often the webserver runs as www-data but if you're not sure, run top and you can see the "USER" of php, nginx, etc.

2. 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, cd to the directory that holds all your domains.

3. chown -R www-data:www-data example.com This 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 account they mean FTP account (aka not the cgi deamon/php user/...).