Have samba (4.16) sharing some linux drives to Windows. Want things pretty simple where files on the share are all forced into certain user, gorup, mode:
force create mode = 0660 force directory mode = 02770 force user = samba
Everything works great. The files get created like this:
-rw-rw---- 1 samba samba 0 Jan 4 01:01 test-file.txt
... With every app except MS Office. MS Office insists on making some fubar ACL:
-rw-rwx---+ 1 samba samba 50510 Jan 4 01:13 test-excel.csv*
#getfacl test-excel.csv # file: test-excel.csv # owner: samba # group: samba user::rw- user:samba:rw- group::rw- group:samba:rw- mask::rwx other::---
Looks like the same thing, eh? But that ACL screws up linus backups as it is stopping a user who is in group samba from reading the file!!?!??
But I don't even want to solve that riddle (because they should be able to read it), I just want to force samba to not let (or just ignore) Office make an ACL in the first place. I don't want any files where ls says "+" in the mode!
I swear this didn't use to happen. Might have been years ago, though. All the samba ACL options seem to be to get "more" ACLs. I want less! None!
But I don't want to mount the linux fs itself with ACLs off. I just want to force samba to force Office to not be insane.
Anyone know the magic for this?
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.
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.
-Adam
Get Outlook for Androidhttps://aka.ms/AAb9ysg ________________________________ From: Roundtable roundtable-bounces@muug.ca on behalf of Trevor Cordes trevor@tecnopolis.ca Sent: Friday, January 6, 2023 8:50:39 PM To: MUUG RndTbl roundtable@muug.ca Subject: [RndTbl] weird samba ACLs from MS Office
Have samba (4.16) sharing some linux drives to Windows. Want things pretty simple where files on the share are all forced into certain user, gorup, mode:
force create mode = 0660 force directory mode = 02770 force user = samba
Everything works great. The files get created like this:
-rw-rw---- 1 samba samba 0 Jan 4 01:01 test-file.txt
... With every app except MS Office. MS Office insists on making some fubar ACL:
-rw-rwx---+ 1 samba samba 50510 Jan 4 01:13 test-excel.csv*
#getfacl test-excel.csv # file: test-excel.csv # owner: samba # group: samba user::rw- user:samba:rw- group::rw- group:samba:rw- mask::rwx other::---
Looks like the same thing, eh? But that ACL screws up linus backups as it is stopping a user who is in group samba from reading the file!!?!??
But I don't even want to solve that riddle (because they should be able to read it), I just want to force samba to not let (or just ignore) Office make an ACL in the first place. I don't want any files where ls says "+" in the mode!
I swear this didn't use to happen. Might have been years ago, though. All the samba ACL options seem to be to get "more" ACLs. I want less! None!
But I don't want to mount the linux fs itself with ACLs off. I just want to force samba to force Office to not be insane.
Anyone know the magic for this? _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
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...
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...
On 2023-01-08 Adam Thompson wrote:
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.
I'll look into icron, interesting idea... still kludgy, but instant-kludge instead of nightly kludge.
There's bad news here: https://serverfault.com/questions/828977/how-can-i-stop-samba-from-writing-e....
Ugh, so much for that idea.
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.)
The Windows boxes use the linux samba server/share as the main file share. Linux then later backs up the linux directory that is/was the share.
Anyhow, I started playing with it more and it *may* have just been the program accessing the data that was barfing at the ACLs (rdiff-backup). I updated to a newer rdiff-backup and now I can't reproduce the problem with a simple test case. It's backup up the ACL'd files just fine. Weird. I'm running the entire backups again to see if the non-simple test case barfs again, but it will take a few hours.
Outside the rdiff-backup stuff, I'm doing a simple read test: sudo -u netbak file 22-094U.csv
and it seems to work fine. I could swear reads as the netbak user were denied before, but my earlier tests of that have scrolled off the terminal buffer.
If rdiff plays nice now, I'm happy to just leave the useless Office ACLs as-is and pretend they don't exist. Sounds like fighting with it is Quixotic. If it still causes problems, perhaps the caps are the way to go, I'm pretty sure I could make that work, if they can actually override the ACL blockage. icron as a last resort.
Thanks for the tips. I'm especially happy (well, unhappy) to see the definitive answer in the serverfault article. My google-fu didn't reach that nugget (sigh).
-
Adam Thompson -
Trevor Cordes