[cifs-protocol] [EXTERNAL] SMB2 compound requests handling - TrackingID#2409010040000238

[Jeff McCashland (He/him)]

Hi Ralph,

It was pointed out to me that the compounded SetInfo request in your trace (packet 34} is not an async operation, and that's why it succeeds. The async flag is not set, so there is no need to document an exception.

Am I missing anything?


Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation

Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)

Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300



________________________________
From: Jeff McCashland (He/him) <jeffm at microsoft.com>
Sent: Thursday, September 5, 2024 11:01 AM
To: Ralph Boehme <slow at samba.org>
Cc: cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>; Microsoft Support <supportmail at microsoft.com>
Subject: Re: [EXTERNAL] SMB2 compound requests handling - TrackingID#2409010040000238

[Michael to BCC]

Hi Ralph,

I will dig into the traces you provided, and let you know what I find.


Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation

Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)

Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300



________________________________
From: Michael Bowen <Mike.Bowen at microsoft.com>
Sent: Saturday, August 31, 2024 8:02 PM
To: Ralph Boehme <slow at samba.org>
Cc: cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>; Microsoft Support <supportmail at microsoft.com>
Subject: RE: [EXTERNAL] SMB2 compound requests handling - TrackingID#2409010040000238

Hi Ralph,

Thanks for your inquiry. I've created case 2409010040000238 to track this issue. One of our team members will follow up with you soon.

Best regards,
Michael Bowen

Sr. Escalation Engineer - Microsoft® Corporation

-----Original Message-----
From: Ralph Boehme <slow at samba.org>
Sent: Saturday, August 31, 2024 8:33 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: [EXTERNAL] SMB2 compound requests handling

Hello dochelp!

We recently debugged an issue with macOS client getting an error from Samba when renaming a file.

I tracked this down to a difference in behaviour when receing a compound related request chain of CREATE + SETINFO(rename) + CLOSE. The rename triggers a lease break of a handle lease of another open on the same file by another client.

In Samba we treat the SETINFO(rename) that has to wait for the lease break processing as an async request and then fail the request as we implement the restriction from 3.3.5.2.7 Handling Compounded Requests:

   The server MAY<262> fail requests in a compound chain which require
   asynchronous processing.

Hence the above compound related request chain of CREATE +
SETINFO(rename) + CLOSE fails with NT_STATUS_INTERNAL_ERROR and the client is unhappy. The same request works against Windows, apparently because a SETINFO(rename) that triggers a lease break is allowed in any position in a compound chain by Windows server.

So both a CREATE and SETINFO(rename) are allowed in any position of a compound chain, which is a bit confusing since both request should trigger the exact same async processing and <262> only talks about CREATE.

Additionally another difference is that for the rename no async interim STATUS_PENDING response is sent which seems to violate 3.3.5.2.7.2 Handling Compounded Related Requests:

   When an operation requires asynchronous processing, all the
   subsequent operations MUST also be processed asynchronously.
   The server MUST send an interim response for all such operations
   as specified in section 3.3.4.2.

Is this by design? Did I miss the bits in MS-SMB2 that describe this?
What is the general rule? Are there other special cases?

Another presumable undocumented behavior is that in a series of compound CREATE + NOTIFY requests, the CREATE response and the PENDING response for the NOTIFY are sent in two different SMB2 response packets.

3.3.5.2.7.2 Handling Compounded Related Requests only has a SHOULD here:

   When all operations are complete, the responses SHOULD be
   compounded into a single response to return to the client.

In my testing NOTIFY seems to be the only request that triggers this splitting of compound requests into seperate responses, but I certainly didn't cover all cases and wonder if there may be other scenarios where this happens. From hard lessons learned in the past, we know that such subtle differences sometimes make the difference between a happy client and a broken one, so I'd highly appreciate some clarification on this one too. :)

Attaching two network traces that cover both scenarios taken against a Windows server.

I'll be at SDC, if you like we can discuss this there. :)

Thanks!
-slow

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20240916/37e550d3/attachment.htm>