Windows 10 client opens a folder as a file and asks for SMB2 GetInfo SMB2_FILE_STREAM_INFO

[Jeremy Allison]

On Fri, May 01, 2020 at 03:55:49PM +0000, Ashok Ramakrishnan via samba-technical wrote:
> Hi:
> We use 4.9.4 based samba in our product and one of our customers is running into a strange issue. If they right click on a folder and get the properties, it reports incorrect size information. When we looked at the network trace, we see that the client is walking the tree and getting information about files and folders.. Suddenly out of the blue, it opens a folder (which it had previous opened and closed as a directory) as a file (Create Options 0x00200020) and then issues a getino file stream info call. Samba promptly responds to this with NO_DATA since there is no stream associated with this folder. After this, things go downhill.. The client starts requesting files with paths without the above folder in the path and rightly gets STATUS_OBJECT_NAME_NOT_FOUND. We have requested our customer to open a support case with Microsoft to help understand the reason for the client behavior... But hoping someone here has had experience troubleshooting similar issues and can provide some tips/pointers on what to look for. I am primarily trying to figure out what could prompt the client to open a folder it knows is a folder, as a file and ask for the stream info. I have looked through the file ID, QFid, etc for any duplication and could not find any. So, why would the client do this? And it does not do this for 99% of the folders in the tree.. Just for a few...
> 
> Thanks!
> 
> 
> -----------
> Frame showing the path being opened as a directory...
> 
> Frame 65257: 706 bytes on wire (5648 bits), 706 bytes captured (5648 bits) on interface \Device\NPF_{B68E32C7-33A6-49BB-BD17-84680A37AE6E}, id 0
> ...
> 
> Then the client does a SMB2_FIND_ID_BOTH_DIRECTORY_INFO to list the contents of the directory...followed by this...It opens the same path without explicitly asking to open a directory (Neither 0x20 not 0x40 is set in the Create Options).
> 
> ----------------
> Frame 65263: 682 bytes on wire (5456 bits), 682 bytes captured (5456 bits) on interface \Device\NPF_{B68E32C7-33A6-49BB-BD17-84680A37AE6E}, id 0
> ...
> Transmission Control Protocol, Src Port: 63880, Dst Port: 445, Seq: 5539052, Ack: 5900825, Len: 628
> NetBIOS Session Service
> SMB2 (Server Message Block Protocol version 2)
>     SMB2 Header
>         ProtocolId: 0xfe534d42
>         Header Length: 64
>         Credit Charge: 1
>         Channel Sequence: 0
>         Reserved: 0000
>         Command: Create (5)
>         Credits requested: 0
>         Flags: 0x00000010, Priority
>         Chain Offset: 0x00000208
>         Message ID: Unknown (65656)
>         Process Id: 0x0000feff
>         Tree Id: 0x12c24d77
>         Session Id: 0x00000000771ae25b
>         Signature: 00000000000000000000000000000000
>         [Response in: 65264]
>     Create Request (0x05)
>         StructureSize: 0x0039
>         Oplock: No oplock (0x00)
>         Impersonation level: Impersonation (2)
>         Create Flags: 0x0000000000000000
>         Reserved: 0000000000000000
>         Access Mask: 0x00100080
>         File Attributes: 0x00000080
>         Share Access: 0x00000007, Read, Write, Delete
>         Disposition: Open (if file exists open it, else fail) (1)
>         Create Options: 0x00200020

This is the key field. It's asking for a reparse point:

FILE_OPEN_REPARSE_POINT 0x00200000

which we're just ignoring. We probably shouldn't.

Reparse points can exist on both files and directories,
but we don't (currently) support them and just ignore
requests for them in the server.

Note we didn't return the FILE_ATTRIBUTE_REPARSE_POINT 0x0400
value in the attributes, so the client shouldn't be doing
that.

We should probably return NT_STATUS_NOT_A_REPARSE_POINT
on the create request here. Note if specifically asked
FSCTL_GET_REPARSE_POINT we do already return NT_STATUS_NOT_A_REPARSE_POINT.

Let me know if you can reproduce this, at will, I
can send you a test patch.

Jeremy.