Bug 12803 - File open for writing with SMB2 using libsmbclient fails
Summary: File open for writing with SMB2 using libsmbclient fails
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 4.2.10
Hardware: x64 Linux
: P5 regression (vote)
Target Milestone: 4.7
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-24 15:27 UTC by Szilard Matyas
Modified: 2017-12-04 09:20 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Szilard Matyas 2017-05-24 15:27:07 UTC
File open for writing using libsmbclient works with SMB1, but not with SMB2. 

Client: Linux with Samba 4.2.10
Server: Windows 2012 R2

File creation is ok, but for the getinfo request the file server gives access-denied for some reasons. The user has full access with SYNCHRONIZE turned on and additionally owner of the directory. Are you aware of any known issue with this setup?

From client to server:

SMB2 (Server Message Block Protocol version 2)
    SMB2 Header
        Server Component: SMB2
        Header Length: 64
        Credit Charge: 1
        Channel Sequence: 0
        Reserved: 0000
        Command: GetInfo (16)
        Credits requested: 7904
        Flags: 0x00000000
        Chain Offset: 0x00000000
        Message ID: 11
        Process Id: 0x00000000
        Tree Id: 0x00000005  \\xxxx-xxxx-xxx03.xxxxxxxxxxx.com\datafiles
        Session Id: 0x0000400000000d11 Acct:srv_xxxxx_test Domain:xxx Host:xxxx-xxxx-xxx09
            [Account: srv_xxxxx_test]
            [Domain: xxx]
            [Host: xxxx-xxxx-xxx09]
            [Authenticated in Frame: 679]
        Signature: 00000000000000000000000000000000
        [Response in: 712]
    GetInfo Request (0x10)
        StructureSize: 0x0029
        Class: FILE_INFO (0x01)
        InfoLevel: SMB2_FILE_ALL_INFO (0x12)
        Max Response Size: 65535
        unknown: 00000000000000000000000000000000
        GUID handle File: Log\2017.05.24\smbtest_trad_profile_dump.log
            File Id: 00055022-0010-0000-0100-000010000000
            [Frame handle opened: 706]
            [Frame handle closed: 713]


From server to client:

SMB2 (Server Message Block Protocol version 2)
    SMB2 Header
        Server Component: SMB2
        Header Length: 64
        Credit Charge: 1
        NT Status: STATUS_ACCESS_DENIED (0xc0000022)
        Command: GetInfo (16)
        Credits granted: 33
        Flags: 0x00000001, Response
        Chain Offset: 0x00000000
        Message ID: 11
        Process Id: 0x00000000
        Tree Id: 0x00000005  \\xxxx-xxxx-xxx03.xxxxxxxxxxx.com\datafiles
        Session Id: 0x0000400000000d11 Acct:srv_xxxxx_test Domain:xxx Host:xxxx-xxxx-xxx09
            [Account: srv_xxxxx_test]
            [Domain: xxx]
            [Host: xxxx-xxxx-xxx09]
            [Authenticated in Frame: 679]
        Signature: 00000000000000000000000000000000
        [Response to: 710]
        [Time from request: 0.000107000 seconds]
    GetInfo Response (0x10)
        [Class: FILE_INFO (0x01)]
        [InfoLevel: SMB2_FILE_ALL_INFO (0x12)]
        StructureSize: 0x0009
        Reserved: 0x0000
        Byte Count: 0
        Error Data: 00
Comment 1 Stefan Metzmacher 2017-06-29 13:18:00 UTC
As 4.7 will use SMB2/3 as default we should make sure this is fixed.

Can you please try to reproduce this with 4.7.0rc1 (will be released next week)
or the current git master branch?
Comment 2 Szilard Matyas 2017-11-10 14:28:51 UTC
Sorry for the late answer......
troubleshooting it further showed we opened the file only for writing with no read access. 
Then positioning with seek resulted in the below mentioned "SMB2_FILE_ALL_INFO" call which requires read access on the server side (Microsoft). That was the call below what gave "STATUS_ACCESS_DENIED". 

We had the impression no read access is necessary for only writing a file.
This only happens with SMBv2 and above, SMBv1 is fine.
Comment 3 Szilard Matyas 2017-12-04 09:20:08 UTC
It is not a bug. Please, close it.