When migrating a Drupal 8 site to a remote server the directory sites/sitename.com/private/config is not assigned to the web server group. It is on the master server but the remote server remains in the aegir group. This leads to an error warning in Drupal 8 status pages about the private sync directory not existing (it does exist but aegir can't access it due to it not being in web server group).

#10 fixconfigperms.patch978 bytesac
Members fund testing for the Drupal project. Drupal Association Learn more


ac created an issue. See original summary.

ac’s picture

Anyone else seeing this?

ergonlogic’s picture

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:

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.

ac’s picture

Thanks for the reply. I can rule out 5 and 6 now (many other working platforms and sites - just no d8 platforms that work). I will go through 1 - 4 and get back to you.

ac’s picture

To replicate what I did, clone a working site with correct permissions for the directories in question from a d8 platform on the aegir master to a d8 platform on the remote aegir server.

Regarding your steps:

1) Done
2) It is there
3) It does
4) There aren't

Post clone

On aegir master:

drwxrws--- 5 aegir www-data 4096 Aug 17 01:15 .
drwxr-xr-x 7 aegir aegir 4096 Sep 22 14:12 ..
drwxrws--- 3 aegir www-data 4096 Aug 17 01:15 config
drwxrws--- 2 aegir www-data 4096 Aug 17 01:15 files
drwxrws--- 2 aegir www-data 4096 Aug 17 01:15 temp

On remote server

drwxrws--- 5 aegir www-data 4096 Sep 22 14:12 .
drwxr-xr-x 7 aegir aegir 4096 Sep 22 14:13 ..
drwxrws--- 3 aegir aegir 4096 Sep 22 14:12 config
drwxrws--- 2 aegir www-data 4096 Sep 22 14:12 files
drwxrws--- 2 aegir www-data 4096 Sep 22 14:12 temp

ergonlogic’s picture

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.

ergonlogic’s picture

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

ergonlogic’s picture

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.

ac’s picture

Any chance of getting a temporary fix to drush_provision_drupal_pre_provision_deploy()

This is a pretty annoying bug.

ac’s picture

978 bytes

Patch attached. Fixes the issue for D8 sites, has no impact on D7 sites.

helmo’s picture

Status: Active » Reviewed & tested by the community

  • helmo committed 0c3b924 on 7.x-3.x authored by ac
    Issue #2888283 by ac: Not updating ownership of private/config
helmo’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.