Bug 2346 - saving excel files when using ACLs gives problems with permissions
Summary: saving excel files when using ACLs gives problems with permissions
Alias: None
Product: Samba 3.3
Classification: Unclassified
Component: Build environment (show other bugs)
Version: 3.3.4
Hardware: x86 Linux
: P3 major
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
: 1280 (view as bug list)
Depends on:
Blocks: 4308
  Show dependency treegraph
Reported: 2005-02-15 02:03 UTC by Olaf Fraczyk
Modified: 2020-12-11 11:17 UTC (History)
11 users (show)

See Also:

Patch to fix read-only problem by Excel (792 bytes, patch)
2005-03-22 17:37 UTC, MORIYAMA Masayuki
no flags Details
smbd.log (785.59 KB, text/plain)
2005-03-24 22:47 UTC, MORIYAMA Masayuki
no flags Details
tcpdumps and level 10 logs (308.42 KB, application/octet-stream)
2005-05-02 13:00 UTC, John Janosik
no flags Details
Proposed patch for jpjanosi@us.ibm.com (1.15 KB, patch)
2005-05-09 17:03 UTC, Jeremy Allison
no flags Details
Patch for v3-3-test and v3-2-test (2.10 KB, patch)
2009-05-08 10:30 UTC, Stefan Metzmacher
metze: review? (jra)

Note You need to log in before you can comment on or make changes to this bug.
Description Olaf Fraczyk 2005-02-15 02:03:15 UTC
I have checked it with Windows share, and the problem is specific to

The share is set as follows:

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:

# owner: piotr
# group: users

When you have file:
# file: Commercial.xls
# owner: piotr
# group: users

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

Don't know why this message appears, as it has plenty memory free.

Then I see:
# file: Commercial.xls
# owner: aga
# group: users

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

[root@venus WYNAGRODZENIA]# getfattr -d Commercial.xls
# file: Commercial.xls

I also tried to use:

force create mode = 0700

to ensure that the owner always gets "rwx" right, but it changed

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
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.
Comment 1 Totem (dead mail address) 2005-03-11 12:39:30 UTC
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

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

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

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

Here is the share definition in smb.conf:

        comment = Main File Share
        path = /samba/share
        read only = No
        inherit permissions = Yes
        map acl inherit = Yes
        hide unreadable = Yes
        map archive = No
Comment 2 Jeremy Allison 2005-03-11 19:08:04 UTC
I'll take a look at this. Jeremy.
Comment 3 Jeremy Allison 2005-03-11 19:19:05 UTC
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.
Comment 4 Jeremy Allison 2005-03-11 19:27:59 UTC
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.
Comment 5 Olaf Fraczyk 2005-03-14 03:32:42 UTC
(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.
primary group: users, supplementary: administracja
primary group: users, supplementary: administracja,dyrekcja

BTW. One interesting thing is, that Excel creates temporary file with "correct"
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".

Comment 6 Totem (dead mail address) 2005-03-14 11:35:57 UTC
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:

        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

        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
Comment 7 Totem (dead mail address) 2005-03-14 11:42:50 UTC
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."
Comment 8 Totem (dead mail address) 2005-03-14 17:45:49 UTC
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?
Comment 9 MORIYAMA Masayuki 2005-03-22 17:37:37 UTC
Created attachment 1087 [details]
Patch to fix read-only problem by Excel
Comment 10 Jeremy Allison 2005-03-24 15:37:24 UTC
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.... :-).
Comment 11 MORIYAMA Masayuki 2005-03-24 22:47:41 UTC
Created attachment 1119 [details]

The reproduction method is as follows. 

1. Settings

smb.conf (samba 3.0.13)
# Global parameters
#	 dos charset = CP932
#	 unix charset = EUCJP-MS
#	 display charset = EUCJP-MS
	workgroup = MYGROUP
	log level = 10

	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)

# file: dev
# owner: root
# group: miracle

# file: test.xls
# owner: takeuchi
# group: miracle

2. Operation with Windows

- C:\> net use z: \\smbserver\development /user:moriyama
- "Z:\test.xls" is opened with Excel 2000. 
- save file

3. Result

# file: test.xls
# owner: moriyama
# group: miracle
Comment 12 Nerijus Baliūnas 2005-04-28 19:48:58 UTC
It's still not fixed in 3.0.15pre2. Patch from MORIYAMA Masayuki helped. Why  
isn't it applied and bug is closed?  
Comment 13 Jeremy Allison 2005-04-30 01:02:17 UTC
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.
Comment 14 John Janosik 2005-05-02 13:00:50 UTC
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

Save file book1.xls in exceltest dir connected as jpjanosi:

[root@rchspeed exceltest]# getfacl Book1.xls
# file: Book1.xls
# owner: jpjanosi
# group: domain users

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

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
Comment 15 Jeremy Allison 2005-05-03 01:49:51 UTC
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.... :-).
Comment 16 Jeremy Allison 2005-05-09 17:03:00 UTC
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 :-).
Comment 17 Jeremy Allison 2005-05-09 17:03:39 UTC
Please take a look at the new patch I added.
Comment 18 Jeremy Allison 2005-05-09 21:21:37 UTC
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...).
Comment 19 Lars Müller 2005-05-17 01:38:55 UTC
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.
Comment 20 Jeremy Allison 2005-05-17 09:18:50 UTC
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 !

Comment 21 John Janosik 2005-05-18 08:31:33 UTC
Sorry for the delay testing.  The patch fixes the problem for me as well.
Comment 22 Jeremy Allison 2005-05-23 13:50:13 UTC
*** Bug 1280 has been marked as a duplicate of this bug. ***
Comment 23 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:18:37 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 24 Diego Remolina (dead mail address) 2006-10-30 10:00:15 UTC
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:
  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.
Comment 25 Matt Gundry 2007-01-31 16:17:17 UTC
(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.
Comment 26 Matt Gundry 2007-02-02 12:01:00 UTC
(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.
Comment 27 Stefan Metzmacher 2009-05-08 10:16:35 UTC
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.

Comment 28 Stefan Metzmacher 2009-05-08 10:30:53 UTC
Created attachment 4130 [details]
Patch for v3-3-test and v3-2-test
Comment 29 Jeremy Allison 2009-05-08 12:14:20 UTC
+1 from me on the patch (for 3.3. and 3.2 also). This is a nice fix.
Comment 30 Karolin Seeger 2009-05-13 11:39:29 UTC
Is the patch ready to get upstream?
If so, please re-assign it to me.
Comment 31 Jeremy Allison 2009-05-13 11:42:19 UTC
Re-assigning to Karolin for upstream inclusion.
Comment 32 Karolin Seeger 2009-05-13 11:50:42 UTC
Pushed, thanks!
Will be included in 3.2.12 and 3.3.5.

Closing out bug report.
Comment 33 Mathieu Parent 2009-05-14 07:42:40 UTC

Has it been fixed in 3.4 and master ?

Comment 34 Karolin Seeger 2009-05-14 07:48:57 UTC
Yep, thanks for the heads up!