Bug 8412 - Microsoft Office 2007 (Microsoft Word) fails to save as on a Samba share with SMB2
Microsoft Office 2007 (Microsoft Word) fails to save as on a Samba share with...
Status: RESOLVED FIXED
Product: Samba 3.6
Classification: Unclassified
Component: SMB2
unspecified
All All
: P5 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks: 8399
  Show dependency treegraph
 
Reported: 2011-08-27 04:01 UTC by Jeremy Allison
Modified: 2011-12-28 03:14 UTC (History)
1 user (show)

See Also:


Attachments
wireshark trace of a "Save As" against a 3.6.0 SMB2 share. (121.23 KB, application/cap)
2011-08-27 04:04 UTC, Jeremy Allison
no flags Details
wireshark trace of a "Save As" against a Windows Vista SMB2 share. (216.80 KB, application/cap)
2011-08-27 04:12 UTC, Jeremy Allison
no flags Details
Patch for smb2.oplock test in smbtorture4 (3.04 KB, patch)
2011-08-29 22:45 UTC, Jeremy Allison
no flags Details
git-am fix for 3.6.1 (3.17 KB, patch)
2011-08-30 00:00 UTC, Jeremy Allison
vl: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2011-08-27 04:01:10 UTC
Using Microsoft Word from Microsoft Office 2007 gives an error message when trying to "Save As" on a Samba 3.6 share with SMB2 enabled.

The problem is the client is attempting to do a RAW_SFILEINFO_RENAME_INFORMATION_SMB2 rename in a SetFileInfo on a handle that has been batch oplocked. Samba explicitly disallows this with NT_STATUS_SHARING_VIOLATION (and we have a smbtorture test that proves this happens against a Windows 7 SMB2 server).

Against a Windows Vista server the rename succeeds (on the same batch oplocked file).

In some way the rename path is different - not sure how yet. I will upload traces of a "Save As" against Samba (which fails), and a "Save As" against Win7 (which succeeds).

Jeremy.
Comment 1 Jeremy Allison 2011-08-27 04:04:36 UTC
Created attachment 6817 [details]
wireshark trace of a "Save As" against a 3.6.0 SMB2 share.

wireshark trace of a "Save As" against a 3.6.0 SMB2 share.

Packet 361 shows the SetInfo request to SMB2 rename on a batch oplocked file (opened in packet 334). Packet 362 shows the NT_STATUS_SHARING_VIOLATION error.
Comment 2 Jeremy Allison 2011-08-27 04:12:13 UTC
Created attachment 6818 [details]
wireshark trace of a "Save As" against a Windows Vista SMB2 share.

wireshark trace of a "Save As" against a Windows Vista SMB2 share.

Packet 298 shows the SetInfo request to SMB2 rename on a batch oplocked file
(opened in packet 228). Packet 303 shows the NT_STATUS_SUCCESS.

Something is different between the opens or the subsequent packet streams in the two cases that means either the batch oplock is lost in some way, or there is a subtlety to the open that allows the rename on the batch oplocked file.

I haven't yet figured it out.

Jeremy.
Comment 3 Jeremy Allison 2011-08-27 16:38:01 UTC
Blocker as MS Office is rather important.
Comment 4 Jeremy Allison 2011-08-29 20:53:33 UTC
Oh... I've reproduced it with my new test program !
Jeremy.
Comment 5 Jeremy Allison 2011-08-29 21:59:39 UTC
Ok, I've figured this out... Patch to follow.
Jeremy.
Comment 6 Jeremy Allison 2011-08-29 22:45:13 UTC
Created attachment 6831 [details]
Patch for smb2.oplock test in smbtorture4

Here is the patch to smbtorture4 that explains the bug.

We were being bitten by an artifact of the smbtorture4 environment. The call : torture_smb2_testdir() returns an open handle on the created directory - with all rights set - including DELETE access !

The reason the rename was being denied, is that under SMB2 (and probably SMB1 as well but we don't have a test for this) the rename fails if the target directory has an open handle on it that includes DELETE access.

The correct fix is to only return NT_STATUS_SHARING_VIOLATION if the target directory is open in that way. Fix to follow.

Jeremy.
Comment 7 Jeremy Allison 2011-08-30 00:00:04 UTC
Created attachment 6834 [details]
git-am fix for 3.6.1

I've already pushed this to master autobuild along with the smb2.oplock torture test patch.

Jeremy.
Comment 8 Linda Walsh 2011-08-30 02:44:56 UTC
So if there's a fake-oplock on a file and someone tries to rename it, the 
new code will return a sharing violation. -- is that what I read?


And you think that all the apps that are currently getting 'access denied'
when they try to save a file by pre-creating name, then renaming a tmp to 
the desired name, will work given this fix?


I know I'm not anywhere near to being on the same level of understanding these
things, but...I seem to be missing something...

Won't they all just fail with 'sharing violation's now instead of permission
problems?


I don't see the part where something automatically ignores a sharing violation and turns it into a saved file...
Comment 9 Jeremy Allison 2011-08-30 03:59:44 UTC
> So if there's a fake-oplock on a file and someone tries to rename it, the 
> new code will return a sharing violation. -- is that what I read?

No.

> And you think that all the apps that are currently getting 'access denied'
> when they try to save a file by pre-creating name, then renaming a tmp to 
> the desired name, will work given this fix?

Yes. I tested them.

> I know I'm not anywhere near to being on the same level of understanding these
> things, but...I seem to be missing something...
> Won't they all just fail with 'sharing violation's now instead of permission
> problems?

No.

> I don't see the part where something automatically ignores a sharing violation
> and turns it into a saved file...

The fix removes the automatic return of "sharing violation"
if a batch or exclusive file is being oplocked, and only returns
this if the parent directory is open for delete access (which
is the real case where "sharing violation" should be returned).

It's the correct fix.

Jeremy.
Comment 10 Jeremy Allison 2011-08-30 04:01:23 UTC
Gah - typo:

I said : "The fix removes the automatic return of "sharing violation"
if a batch or exclusive file is being oplocked,"

and meant to say:

"The fix removes the automatic return of "sharing violation"
if a batch or exclusive file is being renamed,"
Comment 11 Volker Lendecke 2011-08-30 16:48:00 UTC
Comment on attachment 6834 [details]
git-am fix for 3.6.1

Looks okay for 3.6.1, but I think we need to look at the share mode record.
Comment 12 Jeremy Allison 2011-08-30 17:07:08 UTC
Looking at the share mode record give 100% correctness, but at a correspondingly higher cost per rename. I'm ok with this for now, as it covers most of the actual usage. You'd need to have 2 separate clients doing operations in the same directory - where one of them has a directory open for delete (something a Windows client never does to my knowledge) in order to run into this actual case.

In the mean time Karolin please pick for 3.6.1.

Jeremy.
Comment 13 Karolin Seeger 2011-08-30 19:10:33 UTC
(In reply to comment #12)
> Looking at the share mode record give 100% correctness, but at a
> correspondingly higher cost per rename. I'm ok with this for now, as it covers
> most of the actual usage. You'd need to have 2 separate clients doing
> operations in the same directory - where one of them has a directory open for
> delete (something a Windows client never does to my knowledge) in order to run
> into this actual case.
> 
> In the mean time Karolin please pick for 3.6.1.
> 
> Jeremy.

Pushed to v3-6-test.
Re-assigning to Jeremy.
Comment 14 Martin Hochreiter 2011-09-01 06:40:18 UTC
I just want to ask if this is the same problem:

My users open an office (2010) document from a network share, change it and are not able to save it any more - office claims about rights or file not present any more or possible network loss.

I got it working with setting:

"veto oplock files = /*.doc/*.docx/*.xls/*.xlsx/*.pptx/*.ppsx/*.ppt/*.pps"
into the share

and
"
kernel oplocks = no
oplocks = no
level2 oplocks = no
"
globally.

I dont had to do this with samba 3.5.11 and smb1, this is since 3.6.0 and smb2.

.... so is this the same issue?
Comment 15 Jeremy Allison 2011-09-02 01:06:47 UTC
Yes, this is the same issue.
Jeremy.
Comment 16 Jeremy Allison 2011-09-08 05:27:47 UTC
Patch already pushed to 3.6.1.
Jeremy.
Comment 17 Steve Allison 2011-12-28 03:14:35 UTC
This bug had been annoying me last summer so I downgraded to 3.5 in the meantime. I was gutted at the speed loss of going back to SMBv1

Just looking into it again and saw this bug report. Have tested it for 24 hours and so far no complaints.

So, from one Allison to another, I thank you very very very much!