The Samba-Bugzilla – Bug 2382
Excel shared workbook stops working
Last modified: 2005-08-24 10:19:16 UTC
After upgrading to 3.0.11, we cannot use our Shared Workbooks in MS Excel 2000
SP3. If the owner of the file opens the .xls workbook, it works. If other user
(UNIX permissions are OK) opens, the file is opened, but an error is displayed:
"File is locked. In order to save changes to the file, you can either close
the file before making any changes and then re-open it, use Save As (File
menu) to save the file using another file name, or turn off Shared
Workbooks and then save the file."
After pressing OK, I cannot even save to the same filename.
If I uncheck the "Shared file" checkbox, no error occurs.
jeremy, can you bump this one up on your list. We've
got multiple reports on it.
Current thread can be found at
Full text of error message:
"File is locked. In order to save changes to the file, you can either close the
file before making any changes and then re-open it, use Save As (File menu) to
save the file using another filename, or turn off Shared Workbooks and then save
Installing the "Custom Error Messages" add-in does not yield a "Web Info" button
on that error message.
Note from the list. Here is a MS-knowledgebase article on the problem :
Created attachment 1022 [details]
Ok, please give this a try (it's checked into SVN also).
I've realised that the semantics of this patch aren't quite right - I need to
save the pending_modtime only as long as the fsp that received the change time
request is open - the current patch keeps it around for as long as any file open
on the same dev/ino pair is open. I need to add a "pending_modtime_owner" field
to the fsp struct and keep track of who was sent the time change request.
Look for this fix tomorrow (3/10/2005 US Pacific time). The current patch should
work well enough to test against though.
Ok, the modified fix is in the SAMBA_3_0 and HEAD SVN code. I'm testing now with
Office 2003 and so will wait for confirmation from a customer before closing -
but I think this may be fixed now.
I have tested with the new 3.0.12 Debian Binary packages from the Samba
repository, and with NO success. The "user" behaviour is the same, the same
error messages come up.
We are getting the same thing on our server running 3.0.12 compiled from the
tarball. Only the user that is the owner of the file is able to work with a
shared workbook. . Everyone else gets the "File is locked" message even though
we are all members of the group that owns the file.
I've just tried and cannot reproduce this using Office 2003 Professional
version 11.5612.5606 on XP and version 11.6355.6408 on Win2K3.
Is it specific to Office 2000 ? Can you reproduce it on Office 2003 ? I'm trying
to track down if this is a Office version specific bug, in which case I'll
downgrade my version of Office to test.
It's happening for us with Excel 2003 (11.6355.6360) SP1 on Windows XP SP2.
Created attachment 1113 [details]
Ok, I have a working theory for this. It concerns ACLs and what happens
when excel wants to update the filetime on a file the user doesn't own.
Normally you just set the "dos filetime" parameter to allow this (this
causes a timestamp to be updated on a file if you can write to it - normally
POSIX only allows this if you're the owner). I've realised the codepath
here doesn't check ACL semantics. This is a bug we've had since we
introduced ACLs a long time ago but only now seems to have been triggered.
Here is a patch to the just released 3.0.13 that causes ACL entries to be
properly checked when "dos filetime= True" has been set.
Please try this on top of 3.0.13 and let me know if it fixes the issues.
Actually, setting dos filetime = true solved the problem (I thought I had tried
that before, but was it turns out I was editing the wrong conf file.) If I had
known that Excel needs to modify the time on shared files, I would have looked
more closely at it before commenting here. Sorry for the confusion, but
hopefully it will solve the other user's problem.
Thanks - I'm closing this one out.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.