I built a server to host a CMS comparison between Drupal and Wordpress. I frequently use ISPConfig to create all of my sites and it works absolutely perfect. In this case, however, I am on a domain, limited to an internal static IP. Additionally, our in house server admin doesn't like Linux (hasn't used it) so I can't ask him to create a DNS reverse lookup entry for the hostname on the DNS server.

No problem, I thought, I'll just add directories to the default web directory for Drupal and Wordpress, then install Drupal and Wordpress respectively. I created the directories, then, in ISPConfig, proceeded to create ftp users, and redirect each to its new directory. My thought was this will allow the ftp client to create all folders/files with the user/group of the main site, supposing to alleviate all permissions issue.

I created Wordpress, and Drupal databases and users, then attempted to install each CMS.

First up, Wordpress - Wordpress requires the settings configuration file be modified with database information before installing. Once this was done, it installed without an issue.

Next - Drupal - I have never had an issue with installing Drupal when using a server with ISPConfig, so I was very surprised when it failed the installation check due to folder permissions.

I decided to dive into the server and find out what is going on.

First, check the permissions of the drupal directory
webserv:/var/www/drupal/$ ls -al
drwxr-xr-x 9 root root

that's odd, it didn't use web1 client1 for the user and group. Oops, created the directories as root, no big deal, I can change owner
webserv:/var/www/$ chown -hR web1:client0 drupal/

I tried it again, still no luck. Okay, so if Drupal can't create a directory or file, it must not be using the user I just changed the folder/file ownership to.

At this point I know what is happening, but not sure why. ISPConfig uses suEXEC to essentially impersonate a different user. This allows multiple sites to have different users, hardening security since users can't change other user's, or other site's, files. Also, with suEXEC, there is no longer a need to change folder/file permissions for the "public" and yet again reducing risk. Read more here for the details and associated security risks.

Upon inspection of the virtual hosts files for the default site, and the site created by ISPConfig, there are clear differences including clues to my suEXEC issues. Most of the additional entries deal with ISPConfig settings, including suEXEC. I copied the following lines to my default virtual host file:
# suexec enabled
<IfModule mod_suexec.c>
SuexecUserGroup web1 client0
</IfModule>

reloaded apache2
webserv:~$/etc/init.d/apache2 reload

and viola!! it works!

NOTE: You will have to change web1 and client0 to the user and group you need to impersonate.

Summary
Use suEXEC to allow scripts, specifically most CMS installers, to manage files and folders within their website directory. 9 times out of 10 this will fix permissions issues.

Disclaimer: Installing suEXEC is beyond the scope of this article as I install it with ISPConfig during my server setup. You can get a similar install using this guide: The Perfect Server - Ubuntu 12.04 LTS (Apache2, BIND, Dovecot, ISPConfig 3)

Thanks for reading!