Drupal 10, the latest version of the open-source digital experience platform with even more features, is here.Directories in sites/example.com/private/files/ get their ownership set to aegir:aegir, whereas they should be aegir:www-data.
This is worked around easily enough by running
chown -R aegir:www-data files/
A verify doesn't change the ownership, but migrations or clones do.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | provision-allow_recursion_in_verify-1647830-6.patch | 1.73 KB | ergonlogic |
| #4 | provision_fix-private-dir-ownership_1647830-2.patch | 965 bytes | sambonner |
| #2 | provision_fix-private-dir-ownership_1647830-1.patch | 3.68 KB | sambonner |
Comments
Comment #1
dagomar CreditAttribution: dagomar commentedI have this exact same problem. I know I could change this manually, but it would be great if aegir would change the ownership recursively. Note that on inspection the folder private/files does get it's group ownership changed to www-data, as it should, just any child folders are left with aegir:aegir.
Upon further inspection it looks like the code is deliberately not setting ownership recursively (no doubt by design). It also looks like the ownership of folder [sitename]/files is not set recursively, however I did find a difference in ownership between the original and the clone. I have a folder: [sitename]/files/sweaver, which has originally the ownership set to www-data:www-data. On the cloned site its set to aegir:www-data. However, I have a folder: private/files/webform that has in the original setup www-data:www-data, but on the clone it's set to aegir:aegir. So, somewhere something is awry. I hope someone has an idea, because manually adjusting the settings each time I make a clone is a bit of a PITA :)
Comment #2
sambonner CreditAttribution: sambonner commented+1 to this being an issue.
I believe another provision_file()->chgrp task has to be run in deploy.provision.inc to handle sites using private file systems as well as public.
Attached a patch against 6.x-1.x-dev that does this. Tested and working nicely. If this works OK for others it would be good to get this into dev.
Thanks,
Sam
Comment #3
ergonlogic@sambonner: Thanks for the patch!
A couple issues... First, we generally prefer to keep functional changes separate from whitespace fixes, as it makes patch review easier. Secondly, this appears to only add the permission change to 'deploy' tasks, whereas we should probably do it in 'verify' tasks, and possibly elsewhere.
Comment #4
sambonner CreditAttribution: sambonner commentedThanks for the guidance @ergonlogic. It looks like clone, migrate and restore tasks all invoke provision-deploy when running so I think the change in deploy.provision.inc should suffice. Initial site verify tasks correctly set the private dir permissions, its only on migrations/clones etc that ownership gets messed up. The code in _provision_drupal_create_directories() looks to set everything correctly, and is called during a verify task.
I suspect the reason we have the problem with clones and migrations is because the sites are tar'd up and then extracted without preserving ownership for www-data.
I've rerolled the patch without the whitespace fixes, sorry about that.
Comment #5
ergonlogic@sambonner Thanks again! Marking as 'needs review' will get your patch more attention :)
You're right, in 'verify' tasks this is done through _provision_drupal_create_directories(), but it explicitly refuses to recurse into certain directories, including private/files/. This leaves us in the odd situation where migrating or cloning a site can fix an error that verifying a site won't.
But it looks like we might be able to fix this in 'verify' tasks too now. We began excluding recursion into these directories based on #874716: Loss of files directory on remote web servers on migrate/clone. This appears to have been a shortcut solution to #1083366: Make the spokes authoritative for files/ and private/ directories. But since the latter is actually fixed now, we should consider letting verify tasks recurse into these directories also.
Comment #6
ergonlogicPatch for the latter part of my comment in #5. This would be in addition to the one in #4. It basically just reverts part of the "fix" from #874716: Loss of files directory on remote web servers on migrate/clone.
Comment #7
ergonlogicCross-referencing: #1124154: On clone, files in sites/$url/themes get chmod in addition to subdirectories
Comment #8
anarcat CreditAttribution: anarcat commentedI think the reason why this doesn't recurse is because some files will be owned by www-data, which aegir will fail to chown, so it will yield a warning or worse, an error and fail.
this specific situation needs to be tested.
Comment #9
ergonlogicIIRC, we can still copy and delete files we don't own, but have (group) read/write access to. So perhaps we can fake chowning them to aegir:www-data by a copy-delete-rename...
Anyway, there's a patch in #4 that deserves attention regardless of this other stuff.
Comment #10
anarcat CreditAttribution: anarcat commentedIt does seem like a necessity to change the own on the private files... so yay for #4.
Comment #11
ergonlogicMerged the patch in #4 in f488cec.
Setting back to 'needs work' to look at #6 further.
Comment #17
mglamanEdit: We're not experiencing this issue, ownership is properly set. However directories created by Drupal (style/public, etc) don't have permissions changed to 77x
Comment #19
helmo CreditAttribution: helmo at Initfour websolutions commentedThe 6.x-2.x branch will go EOL along with Drupal this week. So I'm closing
this issue. If it remains a confirmed issue in 7.x-3.x, feel free to re-open,
or better yet, create a new issue referencing this one.
Lets continue in #2616426: Add 'fix permissions' task