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

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