Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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).
Comment | File | Size | Author |
---|---|---|---|
#10 | fixconfigperms.patch | 978 bytes | ac |
Comments
Comment #2
acAnyone else seeing this?
Comment #3
ergonlogicFor 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:
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:
Changed group ownership of sites/example.com/private/config/ to www-data'
.aegir:www-data
).www-data
group exists on the remote server.aegir
user is in thewww-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 theaegir
user. It should set proper ownership and permissions, but it can only execute filesystem operations on the remote that it is authorized.Comment #4
acThanks 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.
Comment #5
acTo 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
Comment #6
ergonlogicOk... The actual sync happens in provision_drupal_push_site(). Note that we exclude
files/*
andprivate/*
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:chgrp www-data
on the remote, running another verify, then confirming that the group ownership remains 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.
Comment #7
ergonlogicAha! In drush_provision_drupal_pre_provision_deploy() we
chgrp
private/files
andprivate/temp
, but notprivate/config
.Comment #8
ergonlogicI think we should change the direct calls to
chgrp
indrush_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 toprovision_drupal_push_site()
, and drop the custom handling altogether.Comment #9
acAny chance of getting a temporary fix to drush_provision_drupal_pre_provision_deploy()
This is a pretty annoying bug.
Comment #10
acPatch attached. Fixes the issue for D8 sites, has no impact on D7 sites.
Comment #11
helmo CreditAttribution: helmo at Initfour websolutions commentedComment #13
helmo CreditAttribution: helmo at Initfour websolutions commented