[cifs-protocol] [REG:113102210883291] - [MS-SMB2] 3.3.5.22.1 NT_STATUS_REQUEST_NOT_ACCEPTED?

[Edgar Olougouna]

Volker,

After further review, we will update MS-SMB2 to reflect the observed behavior.
Technically, we agree this is server bug and the product group will assess its impact and the need for a fix. If they choose to fix in a future product release, then the verbiage in the document will reflect the expected behavior. In any case, we will need to update the document.

The issue is that the client is attempting to acknowledge to oplock Level2 when NTFS is in Break-to-none. The fix would be for the SMB server to act the same way as it does with leases. The server would handle the fact that the current state of NTFS requires a lower break. 
The server should "succeed" the Level2 ack and immediately send a break-to-none to the client (and then send an acknowledgement to the File System that it is at None). This coherent since a break to Level2 is async.
In the end, the server have acknowledged it is at None to the file system, it accepted the client's "ack to Level2", it sent a "break Level2 to None" for the client to process so the client arrives at None as well.

As such, MS-FSA 2.1.4.12 correctly documents the process the object store (i.e. NTFS + the oplock package) follows to break an oplock.  We believe MS-SMB2 would be the one requiring the update.

Reference:
MS-FSA 2.1.4.12   Algorithm to Check for an Oplock Break
MS-SNB2 3.3.5.22.1   Processing an Oplock Acknowledgment

Thanks,
Edgar

-----Original Message-----
From: Volker Lendecke [mailto:Volker.Lendecke at SerNet.DE] 
Sent: Wednesday, November 13, 2013 5:06 AM
To: Edgar Olougouna
Cc: 'cifs-protocol at samba.org'; MSSolve Case Email
Subject: Re: [REG:113102210883291] - [cifs-protocol] [MS-SMB2] 3.3.5.22.1 NT_STATUS_REQUEST_NOT_ACCEPTED?

On Wed, Nov 13, 2013 at 03:21:01AM +0000, Edgar Olougouna wrote:
> The last Create is transitioning the oplock state to BREAK_TO_TWO_TO_NONE while the previous oplock BREAK_TO_TWO is still unacknowledged.
> This explains why the ack to Level2 returned the error.
> >From server implementation perspective, you can either explicitly ack straight to None (FSCTL_OPLOCK_BREAK_ACK_NO_2) or ack and end up with either Level2 or None, depending on the state of the oplock when your ack shows up (FSCTL_OPLOCK_BREAK_ACKNOWLEDGE).
> 
> Let's me know whether this helps.

Well, not really. I don't have NTFS available, so I don't have FSCTLs around. I was searching for the explanation of the wire-visible behaviour in MS-SMB2 and MS-FSA. Can you give me pointers where in those documents I can find the explanation, or point me at other protocol document?

Thanks,

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de