jra -- as much as I hate to say it. This is very close to bug 4308. I have level 10 logs from 2 clients that I will upload. Running samba-3.0.33-0.el4.13 (RHEL 4) -- the code that was supplied as a fix for #4308 -- users reported a problem today where a user was not able to write to a file that he previously has access to. All the users on the ACL below are in the group facwrite. As the file is updated, the users have "migrated" from the file owner onto the ACL and sometimes the ACL ends up as: user::r-x. The user/owner then looses access to the file. Here's some snapshots as 2 users opened and edited a file. (But not starting at the beginning. The problem has already happened and vc882l was "locked out" Here is the ACL on the directory: # cd Integration\ Testing/ [root@rchs85gd Integration Testing]# getfacl . # file: . # owner: vc7euu # group: domain\040users user::rwx group::--x group:domain\040admins:rwx group:facwrite:rwx mask::rwx other::--x default:user::rwx default:group::--x default:group:domain\040admins:rwx default:group:facwrite:rwx default:mask::rwx default:other::--x # getfacl New* # file: NewBusinessTestStatus.xls # owner: vc8n7c # group: domain\040users user::rwx user:vc7yvj:rwx user:vc882l:r-x group::--x group:domain\040admins:rwx group:facwrite:rwx mask::rwx other::--x I removed an ACL entry using the Windows GUI to allow everyone to write again. # getfacl New* # file: NewBusinessTestStatus.xls # owner: vc8n7c # group: domain\040users user::rwx user:vc7yvj:rwx group::--x group:domain\040admins:rwx group:facwrite:rwx mask::rwx other::--x Next, vc882l opens and saves the file. For some reason, user::r-x is set. # getfacl New* # file: NewBusinessTestStatus.xls # owner: vc882l # group: domain\040users user::r-x user:vc7yvj:rwx user:vc8n7c:rwx group::--x group:domain\040admins:rwx group:facwrite:rwx mask::rwx other::--x Check time stamp # ls -l New* -r-xrwx--x+ 1 vc882l domain users 47104 Apr 14 08:43 NewBusinessTestStatus.xls 8:45:15 AM: William Marshall: scott can you open and save 8:45:37 AM: scott: Cleared two fields...and saved ok. 8:45:40 AM: scott: closed 8:45:51 AM: William Marshall: vc882l is now broken # getfacl New* # file: NewBusinessTestStatus.xls # owner: vc8n7c # group: domain\040users user::rwx user:vc7yvj:rwx user:vc882l:r-x group::--x group:domain\040admins:rwx group:facwrite:rwx mask::rwx other::--x
Created attachment 4065 [details] level 10 log from 1st client accessing the excel file
Created attachment 4066 [details] level 10 logs from 2nd client accessing the excel file
(In reply to comment #0) > jra -- as much as I hate to say it. This is very close to bug 4308. > > I have level 10 logs from 2 clients that I will upload. Can you provide also the smb.conf file (global and share specific bits are enough)
(In reply to comment #0) > Next, vc882l opens and saves the file. For some reason, user::r-x is set. Does one of the 2 logs you posted capture this event ? I really need to see when the ACL is set.
Simo - I hope the problem is in the trace. I didn't try and read the traces. However, only 2 clients were working on the file. And the trace ran during the whole conversation below, while the ACL changed a few times.
Created attachment 4112 [details] smb.conf, including share pm400fac
User just reported, the ACL "broke" on a file that he is the only person using. Previously we thought that the problem was related to multiple users: Notice - user::r # file: Scheduled\040Jobs\040PM5.xls # owner: vc8n7c # group: domain\040users user::r-- user:root:rw- group::--- group:root:--x group:domain\040admins:rwx group:facwrite:rwx mask::rwx other::--- Last Friday we added the parm "map acl inherit=yes" to the share. On bug 4308 this would make the ACL problem go away. It doesn't seem to be a work-around here.
Simo - last time you and jra mentioned that it would be good to have some debug statements in the ACL code. Did anything get added? And and what log level?
My settings are (were): map acl inherit = No map archive = No map hidden = No map system = No map readonly = yes So this last line might be a config problem. Changing to no and testing.
(In reply to comment #9) > My settings are (were): > map acl inherit = No > map archive = No > map hidden = No > map system = No > map readonly = yes > > So this last line might be a config problem. Changing to no and testing. Bill I can't repro with a sane config. maybe your problem is cause by "map readonly = yes" I strongly suggest that you set it to no and use store dos attributes = yes instead to store dos flags into an exetended attribute instead. I'll try some more and try with map readonly =yes, but if that's the culprit then I'll close this bug as a configuration error, as mapping dos attributes on unix permissions is know to make acls hairy.
(In reply to comment #10) > (In reply to comment #9) > > My settings are (were): > > map acl inherit = No > > map archive = No > > map hidden = No > > map system = No > > map readonly = yes > > > > So this last line might be a config problem. Changing to no and testing. > > > > Bill I can't repro with a sane config. > maybe your problem is cause by "map readonly = yes" > I strongly suggest that you set it to no and use store dos attributes = yes > instead to store dos flags into an exetended attribute instead. > > I'll try some more and try with map readonly =yes, but if that's the culprit > then I'll close this bug as a configuration error, as mapping dos attributes on > unix permissions is know to make acls hairy. > Bah on a second read "map readonly" should do nothing, as the parm name is "map read only" ...
A few bugs ago on a different excel bug, jra told us to try: map acl inherit=yes If we set "map acl inherit=yes" on this share, the problem doesn't happen. On this system, we currently have: testparm -l -v -s | grep -i read map readonly = no There's no space in readonly in the testparm output, so which was is it? Also, I'll agree this appears to be different that what I reported in May.
(In reply to comment #12) > A few bugs ago on a different excel bug, jra told us to try: > map acl inherit=yes > > If we set "map acl inherit=yes" on this share, the problem doesn't happen. Ok I tried with both map acl inherit yes and no and still can't repro. Can you tell me what are the client OSs and what Excel version ? Or have you seen this on multiple client/office versions combination ? > On this system, we currently have: > testparm -l -v -s | grep -i read > map readonly = no > > There's no space in readonly in the testparm output, so which was is it? Bah, go trust smb.conf man page .. I just looked in the code and you are right sir, it's "map readonly". > Also, I'll agree this appears to be different that what I reported in May. What I find also strange is that when I manipulate the files, I don't see new ACLs for the second user changing the file. I just see as owner the initial user that created the file and that seem to never change here. Can you give me an overview of the membership relation between the groups in the ACLs and the users in the ACLs ?
*** This bug has been marked as a duplicate of bug 2911 ***