Created attachment 10965 [details]
Patch for master

I think we have a subtle bug in our handling of compound requests where one of the requests is a read or write that wants to go async. It's caused by a OS X client sending a compound request containing a read or write where the read or write is not the last operation in the chain. This is normally seen in a request by a Mac to create or read a Minshall/French symlink:

smb2 compound request chain: create/getinfo/write/close

In this case, according to [MS-SMB2] section 3.3.5.2.7, footnote 206 we must fail the request with STATUS_INTERNAL_ERROR in case the write requires async processing.

It seems on a normal, that is non-clustered, fileserver the write will usually not require async processing thus the bug is never triggered. I saw this bug on a clustered Samba server, it can be triggered by adding a delay to asys_pwrite_do():

--- a/source3/lib/asys/asys.c
+++ b/source3/lib/asys/asys.c
@@ -189,6 +189,7 @@ static void asys_pwrite_do(void *private_data)
        struct asys_job *job = (struct asys_job *)private_data;
        struct asys_pwrite_args *args = &job->args.pwrite_args;
 
+       sleep(1);
        job->ret = pwrite(args->fildes, args->buf, args->nbyte, args->offset);
        if (job->ret == -1) {
                job->err = errno;

This ensures the aio request is not already finished at the beginning of smbd_smb2_request_pending_queue().

In smbd_smb2_request_pending_queue() the request is then cancelled, but we miss to call tevent_req_error on the smb2 subreq, as a result the server hangs.

Attached patch fixes this for me.

Thoughts?