I'm using the latest dev of provisionacl, and have an issues with files created by the webserver. So, since the server is running as user:group www-data:www-data -- its files get created as such under the example.com/files directory. Files with those user:group settings are unable to be touched by setfacl since they are not owned by user aegir.

If I manually do a

chown -R aegir:www-data

on everything in files and private dirs, then verify works again. So, it seems that a directory or file needs to be owned by user aegir for setfacl to work.

I think it might make sense to not run provisionacl on the "files" or "private" directories?

Comments

anarcat’s picture

anarcat commented

So yeah, I think here the issue is that we shouldn't fail with an error if we fail to apply the ACL.

Can you try with 1.6 to see if this is a regression introduced in 1.7? I suspect it is the case.

chrisschaub’s picture

chrisschaub commented

1.6 tries to set if for files as well. It doesn't fail though. It has other issues related to files, man this is a hornets nest! It seems like perms need to be set up a level -- at the platform level sites dir -- for the acl groups? Ok, thanks.

anarcat’s picture

anarcat commented
Status: Active » Fixed

I fixed this by going through the sites directory recursively itself, instead of explicitely listing the directories, in #1416056: give access to entire site directory (was: add support for .git).

I have also, as a safeguard, made provision not fail on that directory, but only on drushrc/settings.php files. So even if we do try to set ACLs on files/ that we don't own (apart from the settings file), we will just spew a warning.

Status: Fixed » Closed (fixed)

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