[HELP?] Weird problem with SMB client code

[Jeremy Allison]

On Fri, Dec 14, 2018 at 03:41:40PM +1300, Tim Beale via samba-technical wrote:
> I'm hitting a weird problem with the SMB client code. I'll continue
> debugging it in the new year, but just posting it here in case it rings
> any bells with anyone.
> 
> If I have an SMBv2 connection, and cli_list() is the first call I make
> on the connection, then I get an NT_STATUS_INTERNAL_ERROR back from the
> server. I couldn't see any obvious error message on the server (at debug
> level 5).
> 
> It doesn't happen on SMBv1 connections. If I do another SMB operation
> first, then it's fine. E.g. I'm working around the problem by just
> calling cli_list() a 2nd time if it fails.
> 
> It doesn't seem to be a problem with smbclient, but I'm not sure what
> the pylibsmb code is doing differently. The main differences in
> smbclient I could see were:
> - It does a cli_resolve_path() first. I'm not really sure what this is
> doing. I tried it, but it didn't seem to help (but maybe I wasn't
> calling it properly).
> - A slightly different API is used to connect (cli_cm_open() vs
> cli_full_connection_creds_send()).
> 
> If anyone wants to see the problem first-hand, you can checkout the
> tim-smb-wip branch on samba-team/devel/samba.git and then go: make test
> TESTS=samba.tests.ntacls_backup
> The test throws errors:
>     return self.smb_conn.list(smb_path, attribs=SMB_FILE_ATTRIBUTE_FLAGS)
> NTSTATUSError: (3221225701, 'An internal error occurred.')
> 
> Attached is a hacky work-around that makes the problem go away if you
> apply it.

Run with debug level 10 to see if this is a client or
server error.

That should be the first step.

> From fc0a86f2e7331bd3a2eaa99cf1594017f5d5c23f Mon Sep 17 00:00:00 2001
> From: Tim Beale <timbeale at catalyst.net.nz>
> Date: Thu, 13 Dec 2018 16:01:55 +1300
> Subject: [PATCH] TODO: Weird problem with SMBv2 cli_list()
> 
> The first cli_list() call on an SMBv2 connection currently always fails.
> This was being masked in the s4 smb tests because they do a mkdir() in
> the setUp(), which "fixes" the problem. The ntacls tests hit this
> problem, however.
> ---
>  source3/libsmb/pylibsmb.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/source3/libsmb/pylibsmb.c b/source3/libsmb/pylibsmb.c
> index 3e0736d..cb41af1 100644
> --- a/source3/libsmb/pylibsmb.c
> +++ b/source3/libsmb/pylibsmb.c
> @@ -1190,6 +1190,18 @@ static NTSTATUS do_listing(struct py_cli_state *self,
>  	} else {
>  		status = cli_list(self->cli, mask, attribute, callback_fn,
>  				  priv);
> +
> +		// TODO??? This is weird. The first smb_conn.list() call seems
> +		// to fail. Simply repeating the same thing again works. If you
> +		// run another SMB operation (like smb_conn.mkdir()), then it
> +		// also fixes the problem. Forcing SMBv1 (regardless of whether
> +		// sync or async) also avoids the problem. The problem is
> +		// smb2cli_query_directory_recv() returns:
> +		//   NTSTATUSError: (3221225701, 'An internal error occurred.')
> +		if (!NT_STATUS_IS_OK(status)) {
> +			status = cli_list(self->cli, mask, attribute, callback_fn,
> +					  priv);
> +		}
>  	}
>  	TALLOC_FREE(mask);
>  
> -- 
> 2.7.4
>