SMB3 issues with smbclient

Paul Smedley paul at
Tue Dec 20 20:40:18 UTC 2016

Hi Metze!

On 20/12/16 17:39, Stefan Metzmacher wrote:
>>>> On 20/12/16 11:18, Jeremy Allison wrote:
>>>>> On Tue, Dec 20, 2016 at 10:48:35AM +1030, Paul Smedley wrote:
>>>>>> Hi All,
>>>>>> As I've posted previously, I'm working on a Samba client for the OS/2
>>>>>> operating system, which is a fuse style plugin for 'netdrive'.
>>>>>> I've just discovered what I think is a bug in SMB2+ support, which
>>>>>> I believe
>>>>>> also exists in smbclient.
>>>>>> A user reported a problem to me, with file corruption when saving a
>>>>>> file to
>>>>>> a Samba share (the file ends up as 0 bytes),
>>>>>> I believe this is due to an an incorrect fnum being returned from
>>>>>> cli_open()
>>>>>> when SMB2 is used.
>>>>>> In my own code, with a file being opened over SMB1, I get fnum in
>>>>>> the 10000+
>>>>>> range which I'd expect. Additionally, each file opened gets a
>>>>>> differeent
>>>>>> fnum.
>>>>>> When a file is opened via SMB2, in my code fnum is always 1.
>>>>>> I tried similar operations using smbclient - similar things occur:
>>>>>> - SMB1 I get valid fnum returned
>>>>>> - SMB3 I get a fnum of 2 (why this is different to my own testcase
>>>>>> I'm not
>>>>>> sure)
>>>>>> Any thoughts?
>>>>>> Should cli_open() be returning a valid valid for fnum when SMB3 is
>>>>>> used?
>>>>> What version of Samba ? In current 4.5.x cli_open() under the covers
>>>>> will create an SMB1/2/3 handle depending on what has been negotiated
>>>>> on the wire.
>>>> 4.4.7 - I added a d_printf("fnum = %d\n",fnum); after the first
>>>> cli_open()
>>>> call in smbclient and with default settings (ie SMB1) get an fnum like
>>>> 26614; with -mSMB3 - it's always 2.
>>>> I can test with 4.5.x if you think it's worthwhile.
>>> As it's client code it should be relatively easy
>>> to walk through with gdb and watch where it goes
>>> into the SMB2 requests and see what's going wrong.
>> FWIW - same behaviour under linux smbclient with 4.4.8 and 4.5.3
> Why do you think the value '2' is invalid?
> The thing is that we allocate the numbers locally and have
> an in memory mapping from the number to the SMB volatile and persistent
> file id values.
> See source3/libsmb/cli_smb2_fnum.c map_smb2_handle_to_fnum(),
> map_fnum_to_smb2_handle() and delete_smb2_handle_mapping().
> idr_get_new_above() always returns the lowest possible (unused) number,
> so with an open/close, open/close, open/close pattern we'll
> always return the same number, while they point to different
> smb2_hnd structures.
Thanks for the detailed explanation. So as I understand it, for SMB2, 
it's a 'simulated' fd/fnum hence the lower numbering system - so likely 
there's nothing to worry about?

> It would be interesting know if there's actually a real problem.
I will do some more digging - I thought I'd found the silver bullet once 
I identified the significant difference in fnum.

> What was the problem in your case? Did you send the value "1" over
> the net?

In this case, a particular application (MED editor) when saving a file 
on a SMB2+ share, creates a 0 byte file. Same application and plugin 
over SMB1 works fine.

I'll comb back through the logs and potentially add some more logging 
and see what I can fine.

I'll also test against a Win2k server, just to rule out the issue being 
with Samba Server.

Thanks for your input!



More information about the samba-technical mailing list