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