Then entire Office suite does this, AFAIK, in order to ensure the file is correctly prepared for any future "sharing" operation via Sharepoint, OneDrive (really just Sharepoint in disguise), etc., etc. It's technically "correct" behaviour, although unwanted in this case. If anyone else built an app on the same underlying libs/framework that Office uses, presumably it would do the same thing. I'm sure if we looked hard enough and long enough Office wouldn't be the *only* apps doing this.
As to setfacl... I'd use icron(8) to do that instantly instead of in a batch process. Neutering ACLs on the share would be far more efficient if that's your concern.
There's bad news here: https://serverfault.com/questions/828977/how-can-i-stop-samba-from-writing-e.... Quickbooks might also do ACL weirdness: https://krypted.com/windows-server/disable-acls-for-smb/
SELinux would definitely be able to block the creation of the ACL in the first place, if you limit Samba's ability to use ... oh. Ugh. About 30 different functions.
Alternatively, if you could find a way to run the backup process with CAP_FOWNER and/or CAP_DAC_OVERRIDE and/or CAP_DAC_READ_SEARCH that might work around the entire problem. Do the backups run *through* Samba, or locally some other way? If locally see capsh(1). (I'm unclear whether setcap(8) works like chown -S or what it does, really. But capsh should work.) Only thing I can think of if it's done via Samba is to backup the same directory via a different fileshare that has different security overrides on it.
-Adam
-----Original Message----- From: Trevor Cordes trevor@tecnopolis.ca Sent: Saturday, January 7, 2023 6:56 PM To: Adam Thompson athompso@athompso.net Cc: Continuation of Round Table discussion roundtable@muug.ca Subject: Re: [RndTbl] weird samba ACLs from MS Office
On 2023-01-07 Adam Thompson wrote:
I don't remember the exact method, but you want to remove ACL support completely - whether from the FS, Samba, or the share. Office will always do this - but it should be a "so what" moment.
Well, if the ACL isn't doing anything, it's just wasting a block on my disk, and slowing down access to the file as yet another block has to be looked at. Ya, not a big deal, but you know me, I'm persnickety.
IMHO you're focused on a band-aid for the symptom, not the problem. The problem is why does this seemingly-innocuous ACL cause problems? Possibly also why does Samba not translate that back into ordinary UNIX permissions, which in this case looks like fully reversible transform.
Yes, it does, doesn't it. I have a feeling it might have something to do with the strange "full-control" mapping samba does, and there are tuneables for that.
Open to more ideas! I'll toy with the samba options to see if I can get it to return to sanity.
I guess I can poke around more to see why group samba can't read with that ACL... thought it's so bonkers that I didn't even want to go down that rabbit hole.
Trying really hard to not do one suggestion: cron.daily find -exec setfacl -b {} ;
Lastly, wonder why no other app besides Office does this...