samba - Mar 2026 - SMB3 Unix Extensions - creating special files

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 at pali/


----
Nikkos Svoboda


On 3/2/26 09:09, Matthew Richardson via samba wrote:
> Hi,
> 
> Just got back to testing this and wondering if these patches made it into
ML?
> 
> I've tested with 6.17 (Ubuntu Noble standard kernel) and latest 6.19
(mainline) and am seeing odd behaviour where it is creating regular files with
'special' metadata rather than 'real' special files. (This might
be a different issue of course!). Reading existing special files (created on
'real' fs) works fine.
> 
> I'm basically using the same config as in my original post - server is
running 4.23.6 with the following config:
> 
> [global]
>      workgroup = WORKGROUP
>      security = user
>      map to guest = never
>      log level = 3
>      guest ok = no
>      smb3 unix extensions = yes
>      follow symlinks = yes
> 
> 
> [myshare]
>      path = /mnt/users
>      browsable = yes
>      writable = yes
>      read only = no
>      valid users = sambauser #uid/gid 1000
>      create mask = 0777
>      directory mask = 0777
> 
> Client is mounting as:
> 
> mount -t cifs //server.example.com/myshare /mnt/smb -o
posix,vers=3.1.1,username=sambauser,pass=testing123
> 
> Reading existing special files created on real fs works fine:
> 
>> stat test_local
> 
> stat test_local
>    File: test_local -> test.txt
>    Size: 5               Blocks: 1          IO Block: 16384  symbolic link
> Device: 0,49    Inode: 1099511631046  Links: 1
> 
> I can then do:
> 
> touch foo
> ln -s foo foo_link
> 
>> stat foo_link
>    File: foo_link -> mnt/smb/foo
>    Size: 23              Blocks: 0          IO Block: 16384  symbolic link
> Device: 0,48    Inode: 1099511629531  Links: 1
> 
> However on 'real' filesystem:
>> stat foo_link
>    File: foo_link
>    Size: 0               Blocks: 0          IO Block: 4194304 regular empty
file
> Device: 3ch/60d Inode: 1099511629531  Links: 1
> 
> getfattr -d x_link
> # file: x_link
> user.DOSATTRIB=0sAAAFAAUAAAARAAAAIAQAAJmcGa5UqtwB
>
user.SmbReparse=0sDAAAoGgAAAAuAC4AAAAuAAAAAABvAHAAdAAvAGMAZQBwAGgALwBzAGMAcgBhAHQAYwBoAC8AdABlAHMAdAAvAHgAbwBwAHQALwBjAGUAcABoAC8AcwBjAHIAYQB0AGMAaAAvAHQAZQBzAHQALwB4AA=>
> Any suggestions appreciated as to what's going wrong - happy to provide
network traces if that's needed.
> 
> Thanks,
> 
> Matthew
> 
> Matthew Richardson <m.richardson at ed.ac.uk> writes:
> 
>> I've just tried the 6.16 kernel from mainline (Linux vm-b
>> 6.16.0-061600-generic #202507272138 SMP PREEMPT_DYNAMIC Sun Jul 27
>> 22:00:36 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux) and while mkfifo
works
>> again, ln -s is still giving 'operation not supported'.
> 
> Yes - mainline is still broken.  I'll send a fix soon to ML.
> The University of Edinburgh is a charitable body, registered in Scotland,
with registration number SC005336. Is e buidheann carthannais a th? ann an
Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.

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 at 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.