filesystems mounted within an SMB share and REPARSE_TAG_MOUNT_POINT

[Daniel Fussell]

On 3/1/23 12:08, Jeremy Allison via samba-technical wrote:
> 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.
>

I've got a new student employee forward-porting our patch from late 
2018/early 2019 for mountpoint detection and setting 
REPARSE_TAG_MOUNT_POINT.

Our first porting attempt didn't seem to work, I'm guessing because of 
the rewite to use *at() and different code paths.  We'd love to work 
with you on this.

Daniel