Re: BUG: SMB3.11 POSIX extensions: Absolute symlinks lose leading slash on creation

That is also strange as in this code reparse=wsl code I do not see any
manipulation with leading slash. There is again just cifs_strndup_to_utf16()
call: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/smb/client/reparse.c?id=780d569e6c4b422290f5cba319eb904b355d64be#n537

When I was adding support for wsl symlinks, I explicitly did tests that
absolute symlinks are correctly created (with leading slash) and that
WSL on Windows was able to correctly recognize those symlinks.
So if it does not work with recent Linux version, then this is
definitely a regression.

On Saturday 27 June 2026 18:43:32 Steve French wrote:
> It also fails with repairs=wsl
> 
> Thanks,
> 
> Steve
> 
> On Sat, Jun 27, 2026, 6:31 PM Pali Rohár <[email protected]> wrote:
> 
> > According to the reparse.c history, the code itself was not changed.
> > Code for creating of reparse=nfs type symlink is here:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/smb/client/reparse.c?id=780d569e6c4b422290f5cba319eb904b355d64be#n470
> > So maybe the cifs_strndup_to_utf16() function was changed and started
> > stripping that leading slash? Just trying to guess something because is
> > sounds strange that it is broken and reparse.c file do not have any
> > change.
> >
> > On Sunday 28 June 2026 01:27:03 Pali Rohár wrote:
> > > Thank for info. For reparse=nfs this is for sure a bug, and IMHO this
> > > has to be a regression. Because when I was sending my patches for
> > > improving symlink and reparse point support, this worked correctly.
> > >
> > > I have tested it (at that time) and absolute symlink with reparse=nfs
> > > was sent with leading / and was created on windows server with leading /.
> > > I also tested interop with MS NFS server and it understood those reparse
> > > points correctly and correctly served those symlinks over NFS protocol
> > > as absolute with leading /.
> > >
> > > On Saturday 27 June 2026 18:21:18 Steve French wrote:
> > > > symlink creation with "posix" (which defaults to reparse=nfs) creates
> > > > the wrong target path when it is an absolute symlink (leading slash)
> > > > e.g.
> > > >
> > > >    ln -s  /mnt/scratch/file6 symlinktofile6
> > > >
> > > > is sent as
> > > >
> > > >    mnt/scratch/file6 instead of /mnt/scratch/file6
> > > >
> > > > and stat shows:
> > > >
> > > > root@smfrench-ThinkPad-P16s-Gen-2:/mnt/scratch# stat symlinktofile6
> > > >   File: symlinktofile6 -> mnt/scratch/file6
> > > >   Size: 17        Blocks: 8          IO Block: 16384  symbolic link
> > > > Device: 0,61 Inode: 403750517   Links: 1
> > > > Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (
> > 1001/testuser)
> > > > Access: 2026-06-27 18:06:36.415314500 -0500
> > > > Modify: 2026-06-27 18:06:36.415314500 -0500
> > > > Change: 2026-06-27 18:06:36.418477300 -0500
> > > >  Birth: -
> > > >
> > > > On Sat, Jun 27, 2026 at 6:16 PM Pali Rohár <[email protected]> wrote:
> > > > >
> > > > > Can you give a full context of the issue/bug? Link would be enough.
> > > > > I just did not caught from this description what is the issue.
> > > > >
> > > > > On Saturday 27 June 2026 18:14:07 Steve French wrote:
> > > > > > Yes - I have verified that it is the client code (so copying Paulo
> > and
> > > > > > Pali who did most of this code) that has the bug.   When the
> > > > > > FSCTL_SET_REPARSE_POINT is sent by the client, the leading '/' is
> > > > > > already stripped off.  This affects both reparse=nfs (default)
> > > > > > and reparse=wsl.    I would recommend mounting instead with
> > > > > > "mfsymlinks" (which is safer for most cases as well since the
> > > > > > symlinks are not processed by the server for the "mfsymlinks"
> > case).
> > > > > >
> > > > > > Paulo and Pali,
> > > > > > Any ideas about this bug with absolute pathnames in symlinks being
> > > > > > broken with reparse points by stripping off the leading slash?
> > > > > >
> > > > > > On Fri, Jun 26, 2026 at 1:15 PM Ralph Boehme <[email protected]>
> > wrote:
> > > > > > >
> > > > > > > On 6/26/26 7:41 PM, Ralph Boehme wrote:
> > > > > > > > Now that we store as empty file + xattr on the server, not real
> > > > > > > > symlinks, this design decision might need to be revisited.
> > > > > > > >
> > > > > > > > I don't remember of the top of my head if this behaviour is
> > implemented
> > > > > > > > in the client or the server. Does anyone remember? I'd have to
> > check.
> > > > > > >
> > > > > > > it's the client: in cifs_convert_path_to_utf16() it strips the
> > leading
> > > > > > > slash for the symlink target when called from
> > create_native_symlink().
> > > > > > >
> > > > > > > As symlinks in SMB3 POSIX may be created any way the server
> > thinks is
> > > > > > > safe (Samba does file+xattr, it never creates real symlinks on
> > the
> > > > > > > server), so symlinks are just a client side thing and we should
> > allow
> > > > > > > creating absolute symlinks. POSIX allows it (and users use it),
> > so we
> > > > > > > should (safely) also allow it in SMB3 POSIX.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Thanks,
> > > > > >
> > > > > > Steve
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks,
> > > >
> > > > Steve
> >