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@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 <[email protected]> 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.


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