I have checked it with Windows share, and the problem is specific to samba. The share is set as follows: [1_REALIZACJA] inherit acls = yes map hidden = no map system = no map archive = no store dos attributes = yes comment = realizacja path = /home/navi/1_REALIZACJA writable = yes printable = no Samba 3.0.11 (and previous :) Windows 2000 PL SP4, Office 2000 PL SP3 The problem is that when a user that is not the owner of .xls file opens it and then saves it, then he gets read-only access to this document. This is a real pain. The parent foleder has the following rights: # file: WYNAGRODZENIA # owner: piotr # group: users user::rwx group::--- group:dyrekcja:rwx group:administracja:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:dyrekcja:rwx default:group:administracja:rwx default:mask::rwx default:other::--- When you have file: # file: Commercial.xls # owner: piotr # group: users user::rwx group::--- group:dyrekcja:rwx group:administracja:rwx mask::rwx other::--- Next user aga opens the file and saves it. The user gets info (from Excel) translated from Polish: "The Document was saved succesfully, but Excel cannot re-open it because of not enough memory available. Please Close the Document and try again." Don't know why this message appears, as it has plenty memory free. Then I see: # file: Commercial.xls # owner: aga # group: users user::r-- user:piotr:rwx group::--- group:dyrekcja:rwx group:administracja:rwx mask::rwx other::--- Next if aga wants to open the document, she gets it read-only. So excel saved the file with new owner, recreated ACL list, but gave the owner only the "Read" right. At the beginning I thought that it is caused by setting (by Excel) the file as "read-only" what would cause samba to map it to "r--" right, but this is not the case. I set: store dos attributes=yes for this share, and the results are the same. So it is not the "read-only" mapping problem: [root@venus WYNAGRODZENIA]# getfattr -d Commercial.xls # file: Commercial.xls user.DOSATTRIB="0x0" I also tried to use: force create mode = 0700 to ensure that the owner always gets "rwx" right, but it changed nothing. Is there any way to ensure the owner/creator to have "rwx" rights? Any idea what causes this "not enough memory" message? The second thing is that after opening this document by 20 persons it will end up with 20 ACL entries. And it is a real hell. I would expect that a. the file owner changes only, and the old owner is not in the new ACL list. or b. the file owner doesn't change, the last accessing user is not added to the list. In Windows the owner changes but no additional ACL entries are added. And the "not enough free memory" problem also is not present in Windows.
I am having this same problem at my company. We recently migrated from our Netware servers. We're using FreeBSD 5.x and Samba 3.0.X. I've tested on two servers and both have the problem. One is Samba 3.0.4 on FreeBSD 5.2.1-RELEASE and the other is Samba 3.0.11 on FreeBSD 5.3-RELEASE-p5. The first is configured as a PDC, the second a BDC, using OpenLDAP. There are POSIX ACL's used on the shares that are having trouble. Here is what I did to recreate the error. It always happens when these steps are followed. 1) I created a spreadsheet called “test.xls” in Excel 2000 on my Windows 2000 workstation. 2) I Made some changes and saved it to a Samba share (mapped drive on my workstation), and then closed the file. # ls -l test.xls -rw-rwx—+ 1 totem wheel 13824 Mar 10 20:47 test.xls # getfacl test.xls #file:test.xls #owner:1000 #group:0 user::rw- group::rw- group:Dept-IT:rwx mask::rwx other::— 3) Using a shell on the server, I modified the owner. # chown testuser test.xls # ls -l test.xls -rw-rwx—+ 1 testuser wheel 13824 Mar 10 20:51 test.xls # getfacl test.xls #file:test.xls #owner:1004 #group:0 user::rw- group::rw- group:Dept-IT:rwx mask::rwx other::— 4) I opened the file again in Windows 2000 (using my account which is not the file owner). 5) I made some changes to the file and saved it. This error message was displayed: “Document saved successfully. Cannot reopen the saved document due to low memory. Please close the document.” 6) The owner and permissions are changed on the server. # ls -l test.xls -r–rwx—+ 1 totem wheel 13824 Mar 10 20:56 test.xls bash-2.05b# getfacl test.xls #file:test.xls #owner:1000 #group:0 user::r– user:testuser:rw- group::rw- group:Dept-IT:rwx mask::rwx other::— Here is the share definition in smb.conf: [share] comment = Main File Share path = /samba/share read only = No inherit permissions = Yes map acl inherit = Yes hide unreadable = Yes map archive = No
I'll take a look at this. Jeremy.
What neither of these reports tell me is what groups the users having problems are in. To reproduce and fix this I need to know what the supplementary groups the connecting user is in. You can get this by logging into the box as that user (at the console) and typing the "id" command to list the userid and supplementary groups. Thanks, Jeremy.
Ok, I just tried to reproduce this and can't with Office 2003. I'll see if I have an Office 2000 installation to test with. Jeremy.
(In reply to comment #4) > Ok, I just tried to reproduce this and can't with Office 2003. I'll see if I > have an Office 2000 installation to test with. > Jeremy. > aga: primary group: users, supplementary: administracja piotr: primary group: users, supplementary: administracja,dyrekcja BTW. One interesting thing is, that Excel creates temporary file with "correct" access. I suppose that Excel at some time sets ACL for this file and doesn't send the owner ACE. And samba adds the "r" right, so the owner has at least read access. The workaround is to use "force security mode = 0600". Olaf
Here are the supplementary groups for the users I am testing with: # id totem uid=1000(totem) gid=513(Domain Users) groups=513(Domain Users), 512(Domain Admins), 1000(Dept-IT), 1004(Userdir Admins), 1005(Desktop Support) # id testuser uid=1004(testuser) gid=513(Domain Users) groups=513(Domain Users) I installed Excel 2003 (build 11.5612.5606). I have the same permissions problem but this time with a new error message: "The document was saved successfully, but Excel cannot re-open it because of a sharing vilation. Please close the document and try to open it again." I tried the proposed workaround but it did not help me. Both of these shares have the same problem: [test] comment = Test path = /samba/share read only = No create mask = 0770 force create mode = 0660 force security mode = 0660 directory mask = 0770 force directory mode = 0770 hide unreadable = Yes map archive = No oplocks = No level2 oplocks = No dos filemode = Yes dos filetimes = Yes [test2] comment = Test2 path = /samba/share read only = No force security mode = 0600 inherit permissions = Yes map acl inherit = Yes hide unreadable = Yes map archive = No
It is me who can't spell, not Microsoft. The error message is "The document was saved successfully, but Excel cannot re-open it because of a sharing violation. Please close the document and try to open it again."
I spoke too soon this morning (blame my pre-caffeinated brain). The workaround does indeed work! Putting "force security mode = 0660" in my share definition seems to fix the problem. I also learned something new. I built a test workstation with a clean copy of Windows 2000 and Office 2000 Standard. I did not apply any patches or hot fixes. With that setup I didn't have the problem. With the workaround not applied, with a fresh Office 2k install, saved Excel files always get the correct permissions. All the machines that are experiencing the problem at my company have the latest OS and Office updates. I decided to try tracking the problem down a little more. I did all the OS and Office updates testing after each reboot. I started getting the error message again after installing Office Service Release 1a (SR-1a). After the update, when I don't have the workaround applied, files are saving as read-only from my test workstation. Can someone try the update to see if they can reproduce the problem?
Created attachment 1087 [details] Patch to fix read-only problem by Excel
Can someone send me a network trace showing this problem, or failing that a debug level 10 from an smbd creating the file with the incorrect ACL. If I can see the problem then I can fix it.... :-). Thanks, Jeremy.
Created attachment 1119 [details] smbd.log The reproduction method is as follows. 1. Settings smb.conf (samba 3.0.13) ---------------------------------------- # Global parameters [global] # dos charset = CP932 # unix charset = EUCJP-MS # display charset = EUCJP-MS workgroup = MYGROUP log level = 10 [development] path = /opt/share/dev read only = No ---------------------------------------- user account ---------------------------------------- uid=500(moriyama) gid=504(miracle) groups=504(miracle),503(dev) uid=502(takeuchi) gid=504(miracle) groups=504(miracle),503(dev) ---------------------------------------- /opt/share/dev ---------------------------------------- # file: dev # owner: root # group: miracle user::rwx group::--- group:dev:rwx mask::rwx other::--- ---------------------------------------- /opt/share/dev/text.xls ---------------------------------------- # file: test.xls # owner: takeuchi # group: miracle user::rwx group::--- group:dev:rwx mask::rwx other::--- ---------------------------------------- 2. Operation with Windows - C:\> net use z: \\smbserver\development /user:moriyama - "Z:\test.xls" is opened with Excel 2000. - save file 3. Result /opt/share/dev/text.xls ---------------------------------------- # file: test.xls # owner: moriyama # group: miracle user::r-- user:takeuchi:rwx group::--- group:dev:rwx mask::rwx other::--- ----------------------------------------
It's still not fixed in 3.0.15pre2. Patch from MORIYAMA Masayuki helped. Why isn't it applied and bug is closed?
I have not applied the patch as it does not look correct to me. I need to understand the underlying problem much better before applying something like this. Jeremy.
Created attachment 1203 [details] tcpdumps and level 10 logs I duplicated the problem on a Samba 3.0.14a server: [root@rchspeed exceltest]# getfacl . # file: . # owner: jpjanosi # group: domain users user::rwx group::--x group:jpjtest4:rwx mask::rwx other::--x default:user::rwx default:group::rwx default:group:jpjtest4:rwx default:mask::rwx default:other::--x Save file book1.xls in exceltest dir connected as jpjanosi: [root@rchspeed exceltest]# getfacl Book1.xls # file: Book1.xls # owner: jpjanosi # group: domain users user::rwx group::--x group:jpjtest4:rwx mask::rwx other::--x Connect as jpjtest(member of group jpjtest4) and save file with changes. tcpdump is called excel.1.trace, level 10 samba log is log.zzoom.1. [root@rchspeed exceltest]# getfacl Book1.xls # file: Book1.xls # owner: jpjtest # group: domain users user::r-x user:jpjanosi:rwx group::--x group:jpjtest4:rwx mask::rwx other::--x Connect as jpjanosi again change the file and try to save. Get file is read only message from excel. tcpdump is called excel.2.trace, level 10 samba log is log.zzoom.2
Eurika ! Those traces have explained it. I know what to do to fix this now, but the proof is too large to fit in the margin of this book.... :-). Jeremy.
Created attachment 1213 [details] Proposed patch for jpjanosi@us.ibm.com I'd really appreciate it if you could try this patch to see if it fixes the problem. I have high hopes of this fix :-). Thanks, Jeremy.
Please take a look at the new patch I added. Thanks, Jeremy.
Ok, I've tried to reproduce this on my XP client with Office 2000 (9.0.3821 SR-1) using the receipe from jpjanosi and of course it doesn't happen to me. Please test with the patch and see if this can be reproduced (hopefully the patch fixes it...). Jeremy.
We got positive feedback from a customer. svn revision 6696 fixed their problems while saving files with Excel 2003 if the file has additional ACLs.
Woo hoo ! Ding dong, the witch is dead :-). I *hated* this bug so much as I wasn't able to reproduce it :-). Closing as it *finally* appears to be fixed ! Jeremy.
Sorry for the delay testing. The patch fixes the problem for me as well.
*** Bug 1280 has been marked as a duplicate of this bug. ***
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
I believe it is very possible this BUG has re-appeared in the 3.0.23b-1 and 3.0.23c-4 releases of samba. I use Jerry's SRPMS for Fedora to build samba on RHEL4 and CENTOS4 machines. I currently have 3.023b in the RHEL4 machines and 3.0.23c on the CENTOS4 machines. I am experiencing the same problems in both machines. 1. Bob opens an excel file and works on it and saves it. 2. Alice opens the excel file, works on it, saves it and gets an error message about an unsuccesful save, however the changes are saved but now the file is read only. 3. Either Bob or Alice try to open the file now, but it is read only. The only work around is to go and right click on the file, uncheck the read-only attribute and then the either user may change the file again. The Share in question has the create and directory masks set as follows: [accounting] path = /export/home/accounting browseable = no write list = @accounting create mask = 660 directory mask = 770 All the servers are using the acl,user_xattr mount options. Please check on this.
(In reply to comment #24) We are seeing this on 3.0.23c on Fedora Core 5 (kernel 2.6.18) as well. User A saves an Excel file and closes it. User B opens it for editing. When user B saves changes they get the "cannot reopen the saved document due to low memory" popup. The file will then have User B as the owner, R set for user, RW for group, and RW set for User A. The Windows file properties dialog shows the read-only box checked. We have set the default ACLs for the parent directory to RWX for user and group. I have experimented with "store dos attributes", "map read only", "map acl inherit", and inherit permissions" to no avail. As is the case with Diego, we have the mount options "rw,acl,user_attr" set on the share.
(In reply to comment #25) An addendum to my last post in case anyone researching this problem wants a fix. I had tried the "force create mode" and "force directory mode" parameters, but they did not seem to make a difference. The last section of Chapter 16 of the Samba 3 HOWTO suggests "force create mode" to workaround the problem for MS Word, but that didn't work for me. On a whim, I tried "force security mode", and everything is now working fine. FWIW.
The problem remains for users exported by winbindd, because create_token_from_username() just fakes the token when the user is not in the local sam domain. This causes user_in_group_sid() to give totally wrong results. In uid_entry_in_group() we need to check if we already have the full unix token in the current_user struct. If so we should use the current_user unix token, instead of doing a very complex user_in_group_sid() which doesn't give reliable results anyway. metze
Created attachment 4130 [details] Patch for v3-3-test and v3-2-test
+1 from me on the patch (for 3.3. and 3.2 also). This is a nice fix. Jeremy.
Is the patch ready to get upstream? If so, please re-assign it to me. Thanks!
Re-assigning to Karolin for upstream inclusion.
Pushed, thanks! Will be included in 3.2.12 and 3.3.5. Closing out bug report.
Hi, Has it been fixed in 3.4 and master ? Thanks
Yep, thanks for the heads up!