Not updating ownership of private/config

For reference, the function where we handle this is: _provision_drupal_create_directories(). As we can see here, it should be setting group ownership of the D8 config dir:

    // d8 support
    $mkdir["sites/$url/private/config"] = 02770;
    $chgrp["sites/$url/private/config"] = d('@server_master')->web_group;

    $mkdir["sites/$url/private/config/active"] = 02770;
    $chgrp["sites/$url/private/config/active"] = d('@server_master')->web_group;

    $mkdir["sites/$url/private/config/sync"] = 02770;
    $chgrp["sites/$url/private/config/sync"] = d('@server_master')->web_group;

We then proceed to create a couple blacklists of paths that we don't want to chmod/chgrp recursively.

Finally, before actually calling the chmod/chgrp operations, we invoke a series of hooks, to allow each of these to be altered. See:

• hook_provision_drupal_chgrp_directories_alter()
• hook_provision_drupal_create_directories_alter()
• hook_provision_drupal_chgrp_not_recursive_alter()
• hook_provision_drupal_chmod_not_recursive_alter()

Note that there appears to be an error in the documentation of the last two hooks (extra 'directories' in their names.)

So, with that background, here are a couple debug steps that'll help to narrow this down:

1. First, run a "verify" task on the site.
2. Check the task log for Changed group ownership of sites/example.com/private/config/ to www-data'.
3. Ensure that the file path on the master server has the correct ownership (aegir:www-data).
4. Check that there are no other warnings in the task log.
5. Check that the www-data group exists on the remote server.
6. Check that the aegir user is in the www-data group on the remote server.

I suspect that last step might be the issue here. Aegir rsync's the platform from the master to the remote server, using the aegir user. It should set proper ownership and permissions, but it can only execute filesystem operations on the remote that it is authorized.

Ok... The actual sync happens in provision_drupal_push_site(). Note that we exclude files/* and private/* unless the remote is part of a cluster. That is, the files on the remote server are generally considered canonical. IIRC, this is to avoid overwriting files on the remote with potentially stale copies on the master.

We occasionally sync files back from the remote too, using provision_drupal_fetch_site(), but that's usually only called prior to a backup.

So, in this case, it looks like private/config was created with the incorrect group ownership and that it then isn't being changed, because the remote server is canonical. It might be worthwhile to test this hypothesis by:

1. Manually running chgrp www-data on the remote, running another verify, then confirming that the group ownership remains correct.
2. Installing a site on the same D8 platform (on the remote server) and confirming that group ownership is correct.

I suspect that, when deploying the backup (as part of the migration) we didn't fix the group ownership early enough, sync'd them out to the remote, and then can no longer affect them.

Aha! In drush_provision_drupal_pre_provision_deploy() we chgrp private/files and private/temp, but not private/config.

I think we should change the direct calls to chgrp in drush_provision_drupal_pre_provision_deploy() to instead call _provision_drupal_create_directories() on the extracted site. In fact, we should be able to do this just before the call to provision_drupal_push_site(), and drop the custom handling altogether.