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

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