Permissions of sites/example.com/files/* incorrect after migration - webserver can not write

Edit 9/24/2010, 7:23 PM: Just solved this again. My last reply was inaccurate.

SUMMARY: I think that there might be a bug here. If you import a site and the files directory is owned by aegir.aegir (the apache user doesn't have correct permissions), provision-verify doesn't set the correct permissions.

Last week I ran into the situation you describe. After discussing it on the aegir list (http://lists.aegirproject.org/pipermail/aegir/2010-September/000020.html) I modified my migrate method and got it working.

Migrate an aegir 0.3 site into aegir 0.4

* create a platform on the 0.4 hostmaster server that is identical to the platform on which the 0.3 site resides.
* create a vanilla site on the new 0.4 platform
* untar the latest backup of the site to be transferred. manually read database.sql into the db that was created when you did step 2.
* as a result of the untarring your files/ dir is owned by your $user.$user (aegir.aegir if that's who you are).

If I verify the site now when it is rsync'd to the webserver I see:

drwxrwx--- 2 app_aegir app_aegir 4096 Sep 24 18:09 sites/testcampuslife-dev.localhost/files/css/

which will cause problems because the webserver user (www-data or apache) can't read that directory. This results in errors like

warning: opendir(sites/testcampuslife-dev.localhost/files/css) [function.opendir]: failed to open dir: Permission denied in /var/aegir/platforms/dev/drupal-6.15/includes/file.inc on line 895.

and

The selected file /var/aegir/platforms/dev/drupal-6.15/sites/testcampuslife-dev.localhost/files/tmp/file7p98cS could not be uploaded, because the destination sites/testcampuslife-dev.localhost/files/js/js_49296e2e0b454ea7cca98dbfb65b7992.js is not properly configured.

If this has happened to you you can correct it thusly:

On the HOSTMASTER server:
* cd to the platform directory
* chgrp -R apache testcampuslife-dev.localhost/files
* reverify the site:

/var/aegir/drush/drush.php --uri='testcampuslife-dev.localhost' provision-save '@testcampuslife-dev.localhost' -v

(Or do the Verify in the hostmaster web UI.)

That should fix it.

I experienced the above using a pre-alpha14 installation.

I guess this isn't really aegir's fault:

The problem is that I migrate in a client's site which has a module enabled which creates a directory. If I forget to do things in the right order apache, not aegir creates the directory.

Here are the bad directories:

drwxrwxr-x 2 apache apache 4096 Oct 8 17:31 css/
drwxrwxr-x 3 apache apache 4096 Oct 8 17:19 ctools/

drwxrwxr-x 3 apache apache 4096 Oct 8 17:31 imagecache/

This is why I suggested the patch attached here: #994210: Add support for some common files/subdirs like css/js/ctools/imagecache.

However, it helps only for those defined subdirectories and not for their sub-sub directories and other directories because of default system umask and different mv/cp actions performed by modules using /files/ directory, so I recommend to fix this on the system level, by forcing umask 002, so it will help also when you are uploading new files. Of course any files you are importing from extracted tar/gz archive, still needs to receive chmod/chown set correctly before verifying the site in Aegir - see my short how-to for Octopus: https://gist.github.com/802945 (of course you could use more advanced chmod for dirs/files separately, but I wanted to keep it simple for new users).

For Debian and Ubuntu the trick is:

apt-get install libpam-umask
echo "UMASK=002" >> /etc/default/login
echo "UMASK 002" >> /etc/login.defs
echo "session optional pam_umask.so umask=0002" >> /etc/pam.d/login

Wondering is this might stem from running drush cron from the wrong user (not apache).

My use-case is that /sites/default/files/ctools/css is getting root ownership which causes a lack of write permissions for the web server user. Since root is required for log writing permissions, I wonder if there might be a way to specify ownership some other way. Hoping the 002 umask will solve this by maintaining apache group writes even though the owner is set wrong.

Is this still an issue with the latest dev branch?

Can we combine this issue with #1615580: New site directory permissions ?