filesystems mounted within an SMB share and REPARSE_TAG_MOUNT_POINT

[Andrew Walker]

On Wed, Mar 1, 2023 at 2:08 PM Jeremy Allison <jra at samba.org> 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'm still slowly investigating things related to this, but it's pretty
clear that nesting submounts in Windows Server can cause problems for the
Linux SMB client

 ```
PS C:\SHARE> fsutil file queryFileID SUBDS/foo
File ID is 0x00000000000000000001000000000026
PS C:\SHARE> fsutil file queryFileID .\SUBDS3\TESTFOLDER\
File ID is 0x00000000000000000001000000000026
```

I generated directories with duplicate file ids (SHARE\SUBDS\foo and
SHARE\SUBDS3\TESTFOLDER) within the SMB share in Windows. The Linux SMB
client gives them the same inode number.

```
root at truenas[/tmpcifs]# stat SUBDS/foo
  File: SUBDS/foo
  Size: 0         Blocks: 0          IO Block: 1048576 directory
Device: 5eh/94d Inode: 281474976710694  Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-03-01 13:13:42.425159200 -0800
Modify: 2023-03-01 13:13:42.425159200 -0800
Change: 2023-03-01 13:13:42.425159200 -0800
 Birth: 2023-02-22 10:49:37.331907600 -0800

root at truenas[/tmpcifs]# stat SUBDS3/TESTFOLDER
  File: SUBDS3/TESTFOLDER
  Size: 0         Blocks: 0          IO Block: 1048576 directory
Device: 5eh/94d Inode: 281474976710694  Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-03-01 12:25:56.283589300 -0800
Modify: 2023-03-01 12:25:56.268165700 -0800
Change: 2023-03-01 12:25:56.268165700 -0800
 Birth: 2023-03-01 11:48:09.617084100 -0800
```

I think handling for submounts will probably need to be fixed in Linux
clients as well.

Andrew