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
compound_create_notify_split_in_response.pcapng.gz
Description: application/gzip
rename_triggers_lease_break_no_pending.pcapng.gz
Description: application/gzip
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
