filesystems mounted within an SMB share and REPARSE_TAG_MOUNT_POINT

[Jeremy Allison]

On Wed, Feb 22, 2023 at 03:30:04PM -0600, Andrew Walker via samba-technical wrote:
>I was recently reviewing fileid behavior in Samba for ZFS datasets mounted
>within an SMB share and decided to see how a Windows server handles such a
>situation (by mounting a separate NTFS volume within an SMB share on Server
>2022 and poking around at it). I can provide pcaps for the morbidly curious.
>
>SUBDS on Windows Server:
>```
>PS C:\SHARE> Get-Item .\SUBDS | format-list
>
>
>    Directory: C:\SHARE
>
>
>
>Name           : SUBDS
>CreationTime   : 2/22/2023 10:45:52 AM
>LastWriteTime  : 2/22/2023 10:45:52 AM
>LastAccessTime : 2/22/2023 10:45:52 AM
>Mode           : d----l
>LinkType       : Junction
>Target         : {Volume{5afcf2e4-f78f-4931-bfb1-a657a2577d06}\}
>```
>
>SMB2 QUERY_DIRECTORY with FileIdBothDirectoryInfo has
>FILE_ATTRIBUTE_REPARSE_POINT set as well as REPARSE_TAG_MOUNT_POINT.
>```
>FileIdBothDirectoryInfo: SUBDS
>    Next Offset: 0
>    File Index: 0x00000000
>    Create: Feb 22, 2023 10:45:52.500407200 Pacific Standard Time
>    Last Access: Feb 22, 2023 10:45:52.500407200 Pacific Standard Time
>    Last Write: Feb 22, 2023 10:45:52.500407200 Pacific Standard Time
>    Last Change: Feb 22, 2023 10:45:56.880741900 Pacific Standard Time
>    End Of File: 0
>    Allocation Size: 0
>    File Attributes: 0x00000410
>    Filename Length: 10
>    Reparse Tag: REPARSE_TAG_MOUNT_POINT (0xa0000003)
>    Short Name Length: 0
>    Reserved: 00
>    Reserved: 0000
>    File Id: 0x001e00000000b590
>    Filename: SUBS
>```
>
>FILE_ATTRIBUTE_REPARSE_POINT is also set in File Attributes on SMB2 CREATE
>response.
>
>Samba currently uses the device ID and inode number to generate 64-bit file
>ids in subordinate filesystems within an SMB share, but it seems like this
>can lead to potential collisions. Windows, for instance, appears to make no
>change to the 64-bit file IDs returned for NTFS volumes mounted within an
>SMB share.
>
>So this is a long way of asking, should we be flagging mounted filesystems
>as reparse points and not altering the inode numbers?
>
>The advantages of this are:
>1. Windows File Explorer GUI clearly labels as a mounted filesystem and not
>a directory
>2. Windows File Explorer GUI clearly shows size of the filesystem
>separately from one being shared.
>3. REPARSE_TAG_MOUNT_POINT can be used by SMB clients to judge whether the
>particular fileid should maybe be treated differently (since it may collide
>with other volume mountpoints). (not sure if any non-MS clients do this).

Very interesting findings Andrew, thanks !

This does indeed look like the correct way forward to cope
with traversing mount points, but the devil (as always) is
in the details.

Prototype code for this would be the next step IMHO.

Jeremy.