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.
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.
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.
Blocker as MS Office is rather important.
Oh... I've reproduced it with my new test program ! Jeremy.
Ok, I've figured this out... Patch to follow. Jeremy.
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.
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.
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...
> 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.
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 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.
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.
(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.
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?
Yes, this is the same issue. Jeremy.
Patch already pushed to 3.6.1. Jeremy.
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!