Re: [Samba] SMB3 Unix Extensions - creating special files

Re: [Samba] SMB3 Unix Extensions - creating special files

[Ralph Boehme]

[-- Attachment #1.1: Type: text/plain, Size: 1342 bytes --]

...adding linux-cifs and Steve to the loop....

Looks to be a client issue: the client is checking for existence of the 
targets, the server returns ENOENT and then that's it. There no attempt 
to create either a symlink nor the fifo as reparse points.

@Steve: any idea of what could be going wrong? Iirc this is supposed to 
be working in the client.

-slow

On 7/30/25 2:31 PM, Matthew Richardson wrote:
> Hi,
> 
> I've created a few network traces which will hopefully help. Each one 
> contains the initial mount command, followed by a single command. 
> They're hosted here:
> 
> https://filebin.net/zvdx07i2m3lta129
> 
> Working:
> 
> samba_stat_symlink.pcap = stat /mnt/sym_a_local
> 
> Not working:
> 
> samba_ln_s.pcap = ln -s /mnt/a.txt /mnt/a.symlink
> 
> samba_mkfifo.pcap = mkfifo /mnt/fifo_new
> 
> Hopefully that will give some idea about what's happening  but let me 
> know if you need any other traces or debug info.
> 
> Thanks,
> 
> Matthew
> 
> 
> On 29/07/2025 18:22, Ralph Boehme wrote:
>> Hi Matthew,
>>
>> as a starting point: can you send us a network trace of this?
>>
>> Iirc the mailing list server is not particularily fond of 
>> attachements, so either put it somewhere to grab it or file a Samba 
>> bug and attach it there.
>>
>> Cheers!
>> -slow
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [Samba] SMB3 Unix Extensions - creating special files

[Steve French]

I will check on this - but looks like the client was running 6.15, so
want to check if there were any fixes in current mainline, 6.16
kernel, which could relate to this.

On Thu, Jul 31, 2025 at 11:12 AM Ralph Boehme <slow@samba.org> wrote:
>
> ...adding linux-cifs and Steve to the loop....
>
> Looks to be a client issue: the client is checking for existence of the
> targets, the server returns ENOENT and then that's it. There no attempt
> to create either a symlink nor the fifo as reparse points.
>
> @Steve: any idea of what could be going wrong? Iirc this is supposed to
> be working in the client.
>
> -slow
>
> On 7/30/25 2:31 PM, Matthew Richardson wrote:
> > Hi,
> >
> > I've created a few network traces which will hopefully help. Each one
> > contains the initial mount command, followed by a single command.
> > They're hosted here:
> >
> > https://filebin.net/zvdx07i2m3lta129
> >
> > Working:
> >
> > samba_stat_symlink.pcap = stat /mnt/sym_a_local
> >
> > Not working:
> >
> > samba_ln_s.pcap = ln -s /mnt/a.txt /mnt/a.symlink
> >
> > samba_mkfifo.pcap = mkfifo /mnt/fifo_new
> >
> > Hopefully that will give some idea about what's happening  but let me
> > know if you need any other traces or debug info.
> >
> > Thanks,
> >
> > Matthew
> >
> >
> > On 29/07/2025 18:22, Ralph Boehme wrote:
> >> Hi Matthew,
> >>
> >> as a starting point: can you send us a network trace of this?
> >>
> >> Iirc the mailing list server is not particularily fond of
> >> attachements, so either put it somewhere to grab it or file a Samba
> >> bug and attach it there.
> >>
> >> Cheers!
> >> -slow
> >>
> >
>


-- 
Thanks,

Steve

Re: [Samba] SMB3 Unix Extensions - creating special files

[Paulo Alcantara]

Ralph Boehme <slow@samba.org> writes:

> ...adding linux-cifs and Steve to the loop....
>
> Looks to be a client issue: the client is checking for existence of the 
> targets, the server returns ENOENT and then that's it. There no attempt 
> to create either a symlink nor the fifo as reparse points.
>
> @Steve: any idea of what could be going wrong? Iirc this is supposed to 
> be working in the client.

With Linux v6.16 and samba master (f1a828016921):

root@fed:~# mount.cifs //192.168.124.1/test /mnt/1 -o username=testuser,password=foo-123,unix
root@fed:~# mount -t cifs
//192.168.124.1/test on /mnt/1 type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=testuser,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.124.1,file_mode=0755,dir_mode=0755,soft,posix,posixpaths,serverino,reparse=nfs,nativesocket,symlink=unix,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
root@fed:~# (cd /mnt/1; rm -rf *; mknod chr c 2 1; mknod blk b 3 4; mknod fifo p; ln -s f0 l0; python -c "import socket as s; sock = s.socket(s.AF_UNIX); sock.bind('sock')"; ls -lh)
ln: failed to create symbolic link 'l0': Operation not supported
total 0
brwxrwxrwx 1 root fsgqa 3, 4 Jul 31 14:31 blk
crwxrwxrwx 1 root fsgqa 2, 1 Jul 31 14:31 chr
prwxrwxrwx 1 root fsgqa    0 Jul 31 14:31 fifo
-rwxrwxrwx 1 root fsgqa    0 Jul 31 14:31 sock

I see a regression when attempting to create symlinks and sockets.  Note
the 'nativesocket' and 'symlink=unix' options, which are definitely
wrong for SMB3.1.1 POSIX mounts.  It should have 'symlink=native' and
'nonativesocket'.

Re: [Samba] SMB3 Unix Extensions - creating special files

[Matthew Richardson]

[-- Attachment #1.1: Type: text/plain, Size: 2198 bytes --]

Thanks for spotting this. I can confirm that I see different behaviour 
with different kernels:

6.13.0 - mkfifo and ln-s work as expected.
6.14.0 - mkfifo works, ln-s gives 'operation not supported'.
 >=6.15.7 - both give 'operation not supported'.

Which implies possibly more than one regression?

Thanks,

Matthew


On 31/07/2025 18:37, Paulo Alcantara wrote:
> [You don't often get email from pc@manguebit.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Ralph Boehme <slow@samba.org> writes:
> 
>> ...adding linux-cifs and Steve to the loop....
>>
>> Looks to be a client issue: the client is checking for existence of the
>> targets, the server returns ENOENT and then that's it. There no attempt
>> to create either a symlink nor the fifo as reparse points.
>>
>> @Steve: any idea of what could be going wrong? Iirc this is supposed to
>> be working in the client.
> 
> With Linux v6.16 and samba master (f1a828016921):
> 
> root@fed:~# mount.cifs //192.168.124.1/test /mnt/1 -o username=testuser,password=foo-123,unix
> root@fed:~# mount -t cifs
> //192.168.124.1/test on /mnt/1 type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=testuser,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.124.1,file_mode=0755,dir_mode=0755,soft,posix,posixpaths,serverino,reparse=nfs,nativesocket,symlink=unix,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
> root@fed:~# (cd /mnt/1; rm -rf *; mknod chr c 2 1; mknod blk b 3 4; mknod fifo p; ln -s f0 l0; python -c "import socket as s; sock = s.socket(s.AF_UNIX); sock.bind('sock')"; ls -lh)
> ln: failed to create symbolic link 'l0': Operation not supported
> total 0
> brwxrwxrwx 1 root fsgqa 3, 4 Jul 31 14:31 blk
> crwxrwxrwx 1 root fsgqa 2, 1 Jul 31 14:31 chr
> prwxrwxrwx 1 root fsgqa    0 Jul 31 14:31 fifo
> -rwxrwxrwx 1 root fsgqa    0 Jul 31 14:31 sock
> 
> I see a regression when attempting to create symlinks and sockets.  Note
> the 'nativesocket' and 'symlink=unix' options, which are definitely
> wrong for SMB3.1.1 POSIX mounts.  It should have 'symlink=native' and
> 'nonativesocket'.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [Samba] SMB3 Unix Extensions - creating special files

[Paulo Alcantara]

Matthew Richardson <m.richardson@ed.ac.uk> writes:

> Thanks for spotting this. I can confirm that I see different behaviour 
> with different kernels:
>
> 6.13.0 - mkfifo and ln-s work as expected.
> 6.14.0 - mkfifo works, ln-s gives 'operation not supported'.
>  >=6.15.7 - both give 'operation not supported'.
>
> Which implies possibly more than one regression?

Yes.  It used to work on older kernels because the client used to create
special files with NFS reparse points by default, which is required for
SMB3.1.1 POSIX mounts.  6c06be908ca1 ("cifs: Check if server supports
reparse points before using them") then added a check for
FILE_SUPPORTS_REPARSE_POINTS, which breaks against samba because it
isn't set.  IOW, we should skip this check for SMB3.1.1 POSIX mounts.

Re: [Samba] SMB3 Unix Extensions - creating special files

[Matthew Richardson]

[-- Attachment #1.1: Type: text/plain, Size: 2509 bytes --]

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

Thanks,

Matthew

On 31/07/2025 19:53, Steve French wrote:
> 	
> You don't often get email from smfrench@gmail.com. Learn why this is 
> important <https://aka.ms/LearnAboutSenderIdentification>
> 	
> 
>> FILE_SUPPORTS_REPARSE_POINTS, which breaks against samba because it
> isn't set.  IOW, we should skip this check for SMB3.1.1 POSIX mounts.
> 
> We did add this patch to 6.16 in mainline
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ 
> commit/fs/smb/client?id=8767cb3fbd514c4cf85b4f516ca30388e846f540 
> <https://eur02.safelinks.protection.outlook.com/? 
> url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2Ffs%2Fsmb%2Fclient%3Fid%3D8767cb3fbd514c4cf85b4f516ca30388e846f540&data=05%7C02%7C%7Cc29b9828335c42fa54f908ddd0638746%7C2e9f06b016694589878910a06934dc61%7C0%7C0%7C638895848082756770%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hQdSVaqJFPIjiwDPuN%2FlOn%2FSqGlqg8Sts1yH272svtA%3D&reserved=0>
> 
> And it should be backported to some stable kernels by now
> Thanks,
> 
> Steve
> 
> On Thu, Jul 31, 2025, 1:15 PM Paulo Alcantara <pc@manguebit.org 
> <mailto:pc@manguebit.org>> wrote:
> 
>     Matthew Richardson <m.richardson@ed.ac.uk
>     <mailto:m.richardson@ed.ac.uk>> writes:
> 
>      > Thanks for spotting this. I can confirm that I see different
>     behaviour
>      > with different kernels:
>      >
>      > 6.13.0 - mkfifo and ln-s work as expected.
>      > 6.14.0 - mkfifo works, ln-s gives 'operation not supported'.
>      >  >=6.15.7 - both give 'operation not supported'.
>      >
>      > Which implies possibly more than one regression?
> 
>     Yes.  It used to work on older kernels because the client used to create
>     special files with NFS reparse points by default, which is required for
>     SMB3.1.1 POSIX mounts.  6c06be908ca1 ("cifs: Check if server supports
>     reparse points before using them") then added a check for
>     FILE_SUPPORTS_REPARSE_POINTS, which breaks against samba because it
>     isn't set.  IOW, we should skip this check for SMB3.1.1 POSIX mounts.
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [Samba] SMB3 Unix Extensions - creating special files

[Paulo Alcantara]

Matthew Richardson <m.richardson@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.

Re: [Samba] SMB3 Unix Extensions - creating special files

[Matthew Richardson]

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


________________________________________
From: Paulo Alcantara <pc@manguebit.org>
Sent: 31 July 2025 21:00
To: Matthew Richardson; Steve French
Cc: Ralph Boehme; Samba Listing; CIFS
Subject: Re: [Samba] SMB3 Unix Extensions - creating special files

Matthew Richardson <m.richardson@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.

[Samba] SMB3 Unix Extensions - creating special files

[Nikkos Svoboda]

   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 <m.richardson@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.

Re: [Samba] SMB3 Unix Extensions - creating special files

[Jeremy Allison]

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.

Re: [Samba] SMB3 Unix Extensions - creating special files

[Jim DeLaHunt]

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

Re: [Samba] SMB3 Unix Extensions - creating special files

[Paulo Alcantara]

Steve French <smfrench@gmail.com> writes:

>> FILE_SUPPORTS_REPARSE_POINTS, which breaks against samba because it
> isn't set.  IOW, we should skip this check for SMB3.1.1 POSIX mounts.
>
> We did add this patch to 6.16 in mainline
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/client?id=8767cb3fbd514c4cf85b4f516ca30388e846f540

This patch doesn't fix the problem with creating symlinks reported by
Matthew.

Note that I've run the tests with v6.16 kernel.

I'll send a follow-up patch soon that fixes both socket and symlink
issues.

Re: [Samba] SMB3 Unix Extensions - creating special files

[Ralph Boehme]

[-- Attachment #1.1: Type: text/plain, Size: 378 bytes --]

On 7/31/25 7:37 PM, Paulo Alcantara wrote:
> I see a regression when attempting to create symlinks and sockets.  Note
> the 'nativesocket' and 'symlink=unix' options, which are definitely
> wrong for SMB3.1.1 POSIX mounts.  It should have 'symlink=native' and
> 'nonativesocket'.

ahh, sorry, but I was kind of expecting that. There are just too many 
options.

-slow

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [Samba] SMB3 Unix Extensions - creating special files

[Paulo Alcantara]

Ralph Boehme <slow@samba.org> writes:

> On 7/31/25 7:37 PM, Paulo Alcantara wrote:
>> I see a regression when attempting to create symlinks and sockets.  Note
>> the 'nativesocket' and 'symlink=unix' options, which are definitely
>> wrong for SMB3.1.1 POSIX mounts.  It should have 'symlink=native' and
>> 'nonativesocket'.
>
> ahh, sorry, but I was kind of expecting that. There are just too many 
> options.

+1

Re: [Samba] SMB3 Unix Extensions - creating special files

[Paulo Alcantara]

Paulo Alcantara <pc@manguebit.org> writes:

> Ralph Boehme <slow@samba.org> writes:
>
>> ...adding linux-cifs and Steve to the loop....
>>
>> Looks to be a client issue: the client is checking for existence of the 
>> targets, the server returns ENOENT and then that's it. There no attempt 
>> to create either a symlink nor the fifo as reparse points.
>>
>> @Steve: any idea of what could be going wrong? Iirc this is supposed to 
>> be working in the client.
>
> With Linux v6.16 and samba master (f1a828016921):
>
> root@fed:~# mount.cifs //192.168.124.1/test /mnt/1 -o username=testuser,password=foo-123,unix
> root@fed:~# mount -t cifs
> //192.168.124.1/test on /mnt/1 type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=testuser,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.124.1,file_mode=0755,dir_mode=0755,soft,posix,posixpaths,serverino,reparse=nfs,nativesocket,symlink=unix,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)
> root@fed:~# (cd /mnt/1; rm -rf *; mknod chr c 2 1; mknod blk b 3 4; mknod fifo p; ln -s f0 l0; python -c "import socket as s; sock = s.socket(s.AF_UNIX); sock.bind('sock')"; ls -lh)
> ln: failed to create symbolic link 'l0': Operation not supported
> total 0
> brwxrwxrwx 1 root fsgqa 3, 4 Jul 31 14:31 blk
> crwxrwxrwx 1 root fsgqa 2, 1 Jul 31 14:31 chr
> prwxrwxrwx 1 root fsgqa    0 Jul 31 14:31 fifo
> -rwxrwxrwx 1 root fsgqa    0 Jul 31 14:31 sock
>
> I see a regression when attempting to create symlinks and sockets.  Note
> the 'nativesocket' and 'symlink=unix' options, which are definitely
> wrong for SMB3.1.1 POSIX mounts.  It should have 'symlink=native' and
> 'nonativesocket'.

Looks like a regression caused by

        6c06be908ca1 ("cifs: Check if server supports reparse points before using them")

By mounting the share again with 'unix,symlink=native,nonativesocket'
and getting rid of this check in cifs_symlink()

	if (le32_to_cpu(pTcon->fsAttrInfo.Attributes) & FILE_SUPPORTS_REPARSE_POINTS)

I was able to create symlink and socket:

root@fed:~# (cd /mnt/1; rm -rf *; mknod chr c 2 1; mknod blk b 3 4; mknod fifo p; ln -s f0 l0; python -c "import socket as s; sock = s.socket(s.AF_UNIX); sock.bind('sock')"; ls -lh)
total 0
brwxrwxrwx 1 root fsgqa 3, 4 Jul 31 14:51 blk
crwxrwxrwx 1 root fsgqa 2, 1 Jul 31 14:51 chr
prwxrwxrwx 1 root fsgqa    0 Jul 31 14:51 fifo
lrwxrwxrwx 1 root fsgqa    2 Jul 31 14:51 l0 -> f0
srwxrwxrwx 1 root fsgqa    0 Jul 31 14:51 sock