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

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