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

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