[Samba] Symlink bugs with SMB3 unix extensions

[Nikkos Svoboda]

    I am currently running Samba server 4.23.3 and clients with kernel 
6.17. Linux clients mount file shares from the Samba server using SMB3 
(3.1.1) with the smb kernel driver.

    My point of asking the following here is to see if anyone knows if 
the behaviors are already known (and perhaps corrected in the lastest 
kernel or Samba version), if these are unknown, or if perhaps these 
might be my fault.



    I see that, when SMB3 unix extensions are enabled (and the client 
mounts with extensions enabled), and 'native' Samba symlinks are being 
used for the client mount, there appear to be two bugs I encounter:

    1)  A client attempting to create a symlink with a leading '/' 
character has to use two '/' as the first character for this to work. 
For instance, [ ln -s /tmp/filetarget linkfile ] ends up creating a link 
as [ linkfile -> tmp/filetarget ], however if the link is created as [ 
ln -s //tmp/filetarget linkfile  ] then the link is created as intended. 
Only the leading forward slash has to be doubled-up in this way.

    2) Additionally, I find that any attempt to create a *relative* 
symlink to a *directory* at the base of the mount produces a permission 
denied error. For instance, if the client mounts a share at 
/home/username , creates a directory /home/username/folder1  , changes 
pwd into the mount tree [ cd /home/username ], and then attempts [ ln -s 
folder1 linkfile ], this produces the error "ln: failed to create 
symbolic link 'linkfile': Permission Denied". This happens *only* to 
folders in the root of the mounted location, with any form of relative 
link that targets an existing folder (like ../../folder1 , ./folder1 , 
etc... from appropriate locations).  Any other symlink target works, to 
other folders not in the root of the mount, and to files or non-existent 
targets in the root of the share mount. Also, a full-path symlink to the 
example target works, while in any pwd [ ln -s //home/username/folder1 
linkfile ].
    I also tried manually creating the extended attribute, "SmbReparse", 
on a file on the server, using a relative link who's creation would have 
been denied on the client, and the client has no problem interacting 
with that symlink.

    I didn't seem to find any settings, other than the choice of 
'native' symlinks (and obviously using unix extensions), that changed 
the above behaviors, though I did not try literally every possible 
permutation of server/mount settings.



    When SMB3 unix extensions are enabled, linux clients see "server 
side" symlinks (files that are actual symlink files on the server's file 
system) as a symlink that they then follow locally, to the target on the 
client. This is *not* true, however, if the two settings "wide links = 
yes" and "allow insecure wide links = yes" in the server's smb.conf 
configuration. In this configuration, the server follows all "server 
side" symlinks on the server and presents the target as a regular file 
to the client (over unix extensions). Having only one of these settings 
set to "yes" does not do this.
    This causes no problems, and I'm not wanting to actually have this 
configuration in production. I can simply think that this *might* not be 
intended behavior for unix extension clients. Is this intended behavior 
for this setting combo?


-- 
---
Nikkos Svoboda