This bug is not a duplicate of #1077 since it was reproduced in samba 3.0.0rc4, 3.0.2, 3.0.2a, 3.0.3pre2, and 3.0.3rc1 Basics: RH AS 3.0 Update 1 Kernel 2.4.21-9.0.1.ELsmp Samba 3.0.2a Filesystem: ext3 Mount options: acl,noatime Config: Role: PDC passdb backend = ldapsam:ldapi://%2fvar%2frun%2fldapi/ Everything works so far. Now the problem: We have a file "example.doc" which is a word 8 (word 97) file. The file is owned by "alice", group "users" getfacl output: # file: example.doc # owner: alice # group: users user::rwx group::r-x group:word:rwx mask::rwx other::--- alice and bob are in the additional group "word": [root@smb01 testdir]# id alice uid=1000(alice) gid=513(users) groups=513(users),1192(word) [root@smb01 testdir]# id bob uid=1001(bob) gid=513(users) groups=513(users),1192(word) Alice can use the file without any problems. Now bob comes along, opens the file, changes it and writes to it. This is what happens to the ACLs/ownership: Bob takes ownership of the file, alice is placed on the ACL with her old rights (rwx) and bob's user write bit is removed. ACL output after the event: # file: example.doc # owner: bob # group: users user::r-x user:alice:rwx group::rwx group:word:rwx mask::rwx other::--- This results in the "write protected" flag being set on the client when looking at it in "Properties...", thus enabling the client to only open the file read only (as bob that is). I was able to track down the problem to the combination of Office 97 running under Windows XP SP1. It does not occur using Office 97 under Windows 9x nor using Office XP / Office 2003 under Windows XP SP1. Overview: Office 97 under XP : BUG Office 97 under 9x : OK Office XP/2k3 under XP: OK I haven't tried any Windows 2000 or Office 2000 versions, as well as no NT or XP without SP1. Office 97 has been tested in the original version, w/ SR-1, and SR-2a. This occurred in a similar setup using XFS w/ ACLs as well. I reproduced the exact setup with a Windows 2000 Server. The file operation worked cleanly there.
Additional info: I did a little bit of further research of that behavior. It occurs to me that the group ownership is changed during the file operation as well. So in alice/bob's case the owning group is set to their primary group (users). The permissions of the owning user is set to the maximum effective permission the user is granted via his primary group membership, that's why in the stated case the write bit is not set, that's where it comes from. If the primary group of the user is not the owning group, the file is chgrp'ed and the former owning group is placed on the ACL just as the former owner. If the group isn't listed in the ACL and isn't the owning group, the permission bits are copied from the "other" permission (o::) and placed on user and group (u::,g::) entries, whilst the "read" bit is always set on the user's perms.
Well... nobody seems to care... too bad! Very disappointing.
don't be disappointed. There are many other bugs which have to be taken care of and there's only little time :(. I have a case where that problem is reproducable.
*** Bug 1395 has been marked as a duplicate of this bug. ***
i have reproduced the same behaviour with xfs acl's + samba 3.0.7 + msoffice2k
I have reproduced the bug on win2K with word 97 ! samba 3.0.7 on RedHat Linux 3 update 3 It seems like if Word would like to delete modifier user's right to put the rights of the creator user. but the modifier user is in the unix rights not in ACL so they can't be deleted ! I open incident to my redhat support and IDEALX support.
(In reply to comment #6) > I open incident to my redhat support and IDEALX support. nobody want to take bug in charge ! "this is a word bug !" this is a pity for a so used soft !
(In reply to comment #7) How can it be a word bug, if it does not occur using a Windows 2000 Server (which I tested)?
please retest 3.0.11 and repoen if the issue still exists. I've reset the version to 3.0.7 (originally report against 3.0.3pre1) based on your comments.
rrenard (irc) says still an issue and will add some comments later today.
Jeremy, could you take a look at this one when you get a chance.
Created attachment 1127 [details] network trace when pressing the save button in word
With 3.0.13 the problem is worse for the user, Word97 cannot save the file under its original name. Data is there but as a backup file. The original file is renamed as a temp file, a new temp file is created, data written to it, but somewhere it is set as read only. word seems to try to change its state to rw, which does not work, then it gives-up asking the user to save the file under the temporary file name (which does not work either). The only workaround is to save the file under a different name. tested with XP-sp2 and Word97-sr2 Excel97 shows no problems
good workaround for those who didn't know this (like me): force create mode = 0660 lot of thanx to Clark Mills c.mills@auckland.ac.nz http://c.mills.ctru.auckland.ac.nz/Samba/XfsAclWinAuth.html
This is a duplicate bug to 2346. I have finally fixed this in SVN source. Please see the patch attached to that bug for the patch. Jeremy. *** This bug has been marked as a duplicate of 2346 ***