Since I started using WordPress (and more importantly developing for WordPress) I have been plagued by what seems to be a very common issue – allowing WordPress to simultaneously have internal writing permissions without breaking FTP. When using WordPress on a linux/*nix server combined with Parallels Plesk, you’re subject to dealing with not only Apache and its permissions, but also the permissions setup by Plesk groups, Plesk users, and Plesk FTP restrictions.
The following steps are what I took to enable full FTP access and full Apache/PHP/system write access to the same directories and files. This was tested on Parallels Plesk v 10.1.1 on a Media Temple (dv) Dedicated Virtual 4.0 running Linux version 2.6.18-028stab093.2. In this configuration, Apache is running under the username Apache, but on other servers may run as www-data, nobody, or something else. You will need shell and sudo access to complete the following tasks.
1. Add the apache user to the psacln (plesk) writable group.
You only need to do this once, however, at this time we have not tested what happens when apache is updated (so you may have to repeat after an update/upgrade)
$ usermod -a -G psacln apache
If the user running the web server is not apache (may be www-data or nobody) simply use that user at the end of this command.
2. You now have to give the group write access on the directories and/or files necessary. In wordpress, you’ll want to do this on the entire directory that wordpress is living in.
$ chmod g+w {file}
$ chmod -R g+w {directory/}
NOTE: After further testing, I’ve updated this to reflect better settings. Essentially we’re giving all folders group write access and all files normal 644 access
$ find wp-content/ -type f -exec chmod 644 {} \;
$ find wp-content/ -type d -exec chmod 775 {} \;
3. Now you have to give ownership to the directories and/or files. The psacln group is specific to plesk and is subject to change based on your environment.
$ chown -R {ftp_username}:psacln {directory}/
4. I suggest you restart Apache once you’re done with these steps, and you may need an Apache restart after step 1 as well. On the Media Temple (dv) 4.0 Dedicated Virtual Apache runs as process httpd, though it may run as apache or something else in your server environment.
$ service httpd restart
5. (Optional) Force WordPress to use the filesystem to run updates. WordPress runs through a routine determining how it’s going to write data (directly, FTP, SSH, etc.) but sometimes fails to use the direct method even though it’s available. Usually there is a reason when WordPress does or doesn’t do something even though it’s possible, so this may be a concern (or it may be a dumb bug). Andrew Nacin has kindly chimed in via the comments to explain this –
The reason WordPress sometimes doesn’t use the direct filesystem method even when it would work is because it only detects that the user on the PHP process is the owner. It doesn’t support detecting group-writeable. … essentially, we’re trying to avoid a situation where we create and therefore own a file, when normally we would not be the owner, and that then locks out the FTP user.
That said, if you’d like to force WordPress to use the direct filesystem to write and modify data, simply add the following line to your wp-config.php file:
define('FS_METHOD', 'direct');
I would love to hear if this worked or didn’t work for you in your own server environment – again, this was a very specific test and I haven’t verified on other hosts, versions of Plesk, or versions of Linux. Please feel free to comment and let everyone know if it worked for you and where.
http://jonathankressaty.com/2011/11/02/plesk-permissions-wordpress-ftp/