Re: SMB3 Unix Extensions - creating special files

On 2026-03-02 17:13, Jeremy Allison via samba wrote:

> On 3/2/26 4:41 PM, Nikkos Svoboda via samba wrote:
>>
>>    Jumping in here briefly, I believe the "default" symlink style 
>> requested by the client mount options is now "symlink=native", which 
>> creates the 0-sized files with extended attributes on the server.
>>
>>    I'd also like to know:  Is it intended to allow creation of 
>> "actual" symlinks on a supported server filesystem via unix 3.1.1 
>> Extensions? The mount option "symlink=unix" (which creates "actual" 
>> symlinks on the server), when used with SMB 3.1.1 unix extensions, 
>> causes symlink creation to fail on the client with "Operation not 
>> supported" (client kernel 6.17, ubuntu 24.04). That mount option 
>> appears to be referred to as "SMB1 unix create symlink command" which 
>> I presume means it is limited to the SMB1 unix extensions.
>>
>>    The archived e-mail conversation chain here (though it includes 
>> some outdated information) helped me to understand some of what the 
>> symlink= and reparse= mount options were intended for:
>> https://lwn.net/ml/all/20241007183650.aw3skuztljpgk2bs@pali/
>
> The goal (at least when I was involved with this effort) was to
> explicitly *ban* SMB3 UNIX extensions ever from creating server-side
> symlinks.
>
> Such activities are inherently unsafe and a source of many, many
> CVE's.

The SMB3 behaviour with server-side symlinks baffled and obstructed me 
greatly, when I switched from connecting my Mac client to the file 
server via AFP to connecting via SMB.

I think there is a conceptual difference here. I think the Samba 
documentation doesn't do a great job of making it explicit. This can 
result in people talking past each other when it comes to symlinks (and 
filename normalisation, and more).

I regard the files on the filesystem as the primary and long-lived 
asset. I regard the filesystem as some sort of idealised POSIX 
behaviour, including symlinks for internal references from one part of 
the served content to another. The data content lasts decades. In that 
time, the server file system may be Linux ext2, then Linux ext3, then 
ZFS. The clients may connect via AFP, or NFS, or SMB. What I want from 
every file access system is to present the server file system transparently.

In contrast, I think the baseline Samba mindset is that the SMB 
presentation of the server content is the primary asset. The presented 
filesystem is some sort of idealised Windows network server. The 
contents of the server filesystem are opaque. The physical files on the 
server should only be accessed via SMB, not by AFP or NFS or by software 
running natively on the server.

If the contents of the server filesystem are opaque, it is 
understandable that SMB might represent what look like symlinks to the 
client as SMB-specific Minshall+French format files. It is 
understandable to SMB might regard server-side symlinks as inherently 
unsafe.

If I could find a way to explain these different conceptual models in 
the Samba wiki, and link from the SMB3 Unix extensions documentation to 
that explanation, I feel I might help other people who are looking for 
the same transparency from SMB which I am. But I have the feeling that 
the conceptual difference is so implicit that there is not a good place 
in the existing structure to put it.

Best regards,
      —Jim DeLaHunt


-- 
.   --Jim DeLaHunt     http://blog.jdlh.com/ (http://jdlh.com/)
       Vancouver, B.C., Canada


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba