[cifs-protocol] SMB2 compound requests handling

[Ralph Boehme]

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 --------------
A non-text attachment was scrubbed...
Name: compound_create_notify_split_in_response.pcapng.gz
Type: application/gzip
Size: 3410 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20240831/aeb0dd47/compound_create_notify_split_in_response.pcapng.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rename_triggers_lease_break_no_pending.pcapng.gz
Type: application/gzip
Size: 13136 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20240831/aeb0dd47/rename_triggers_lease_break_no_pending.pcapng.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20240831/aeb0dd47/OpenPGP_signature.sig>