[PATCH] cifs: Fix support for creating SFU socket

[PATCH] cifs: Fix support for creating SFU socket

[Pali Rohár]

SFU sockets are natively supported by Interix 3.0 subsystem and also by
later versions. It is part of Microsoft SFU (Windows Services for UNIX) and
Microsoft SUA (Subsystem for UNIX-based Applications). They can be created
and existing (stored on local disk or remote SMB share) can be recognized.

SFU sockets are recognized also by NFS server included in Windows Server.
Windows NFS server versions since Windows Server 2012 uses new reparse
point format for storing new sockets, but still can recognize this old
format (also in the latest Windows Server 2022 version).

SFU-style socket is a regular file which has system attribute set and
content of the file is one zero byte.

These SFU-style sockets are already recognized by Linux SMB client.

But Linux SMB client is currently creating new SFU socket in different
format which is not compatible with all those SFU applications. Fix this by
creating new sockets in correct SFU format which would be recognized by all
SFU, SUA, NFS and existing Linux SMB clients.

This change affects only creating new sockets when mount option -o sfu is used.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 fs/smb/client/smb2ops.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
index 4f7eefa7a683..e59fda1b2230 100644
--- a/fs/smb/client/smb2ops.c
+++ b/fs/smb/client/smb2ops.c
@@ -5288,10 +5288,9 @@ int __cifs_sfu_make_node(unsigned int xid, struct inode *inode,
 		data = (u8 *)symname_utf16;
 		break;
 	case S_IFSOCK:
-		type_len = 8;
-		strscpy(type, "LnxSOCK");
-		data = (u8 *)&pdev;
-		data_len = sizeof(pdev);
+		/* SFU socket is system file with one zero byte */
+		type_len = 1;
+		type[0] = '\0';
 		break;
 	case S_IFIFO:
 		type_len = 8;
-- 
2.20.1

Re: [PATCH] cifs: Fix support for creating SFU socket

[Steve French]

AI query made it sound like "LnxSOCK" is still used by WSL.  Is this
change safe?

"Yes. WSL (particularly WSL 1 and WSL 2 when interacting with NTFS via
DrvFs) uses the Lnx* metadata family to represent Linux special file
types, including:

LnxSOCK
LnxFIFO
LnxCHR
LnxBLK"

On Tue, Jul 7, 2026 at 4:13 AM Pali Rohár <pali@kernel.org> wrote:
>
> SFU sockets are natively supported by Interix 3.0 subsystem and also by
> later versions. It is part of Microsoft SFU (Windows Services for UNIX) and
> Microsoft SUA (Subsystem for UNIX-based Applications). They can be created
> and existing (stored on local disk or remote SMB share) can be recognized.
>
> SFU sockets are recognized also by NFS server included in Windows Server.
> Windows NFS server versions since Windows Server 2012 uses new reparse
> point format for storing new sockets, but still can recognize this old
> format (also in the latest Windows Server 2022 version).
>
> SFU-style socket is a regular file which has system attribute set and
> content of the file is one zero byte.
>
> These SFU-style sockets are already recognized by Linux SMB client.
>
> But Linux SMB client is currently creating new SFU socket in different
> format which is not compatible with all those SFU applications. Fix this by
> creating new sockets in correct SFU format which would be recognized by all
> SFU, SUA, NFS and existing Linux SMB clients.
>
> This change affects only creating new sockets when mount option -o sfu is used.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
>  fs/smb/client/smb2ops.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
> index 4f7eefa7a683..e59fda1b2230 100644
> --- a/fs/smb/client/smb2ops.c
> +++ b/fs/smb/client/smb2ops.c
> @@ -5288,10 +5288,9 @@ int __cifs_sfu_make_node(unsigned int xid, struct inode *inode,
>                 data = (u8 *)symname_utf16;
>                 break;
>         case S_IFSOCK:
> -               type_len = 8;
> -               strscpy(type, "LnxSOCK");
> -               data = (u8 *)&pdev;
> -               data_len = sizeof(pdev);
> +               /* SFU socket is system file with one zero byte */
> +               type_len = 1;
> +               type[0] = '\0';
>                 break;
>         case S_IFIFO:
>                 type_len = 8;
> --
> 2.20.1
>
>


-- 
Thanks,

Steve

Re: [PATCH] cifs: Fix support for creating SFU socket

[Pali Rohár]

WSL does not use "LnxSOCK". This looks like an AI hallucination.

WSL stores data in NTFS reparse points:
 IO_REPARSE_TAG_AF_UNIX    - 0x80000023
 IO_REPARSE_TAG_LX_FIFO    - 0x80000024
 IO_REPARSE_TAG_LX_CHR     - 0x80000025
 IO_REPARSE_TAG_LX_BLK     - 0x80000026
 IO_REPARSE_TAG_LX_SYMLINK - 0xA000001D
And also in NTFS EAs:
 "$LXUID"
 "$LXGID"
 "$LXMOD"
 "$LXDEV"

All tests which I have done with WSL's DrvFs resulted in above reparse
points (or in native Windows symlinks).

Some sources which confirms those my testing:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4
https://learn.microsoft.com/en-us/windows/wsl/file-permissions

WSL does not recognize "-o sfu" things at all.

So here I bet that AI "mixed" SFU and WSL formats and parts together and
created that hallucinated answer.

On Wednesday 08 July 2026 08:51:40 Steve French wrote:
> AI query made it sound like "LnxSOCK" is still used by WSL.  Is this
> change safe?
> 
> "Yes. WSL (particularly WSL 1 and WSL 2 when interacting with NTFS via
> DrvFs) uses the Lnx* metadata family to represent Linux special file
> types, including:
> 
> LnxSOCK
> LnxFIFO
> LnxCHR
> LnxBLK"
> 
> On Tue, Jul 7, 2026 at 4:13 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > SFU sockets are natively supported by Interix 3.0 subsystem and also by
> > later versions. It is part of Microsoft SFU (Windows Services for UNIX) and
> > Microsoft SUA (Subsystem for UNIX-based Applications). They can be created
> > and existing (stored on local disk or remote SMB share) can be recognized.
> >
> > SFU sockets are recognized also by NFS server included in Windows Server.
> > Windows NFS server versions since Windows Server 2012 uses new reparse
> > point format for storing new sockets, but still can recognize this old
> > format (also in the latest Windows Server 2022 version).
> >
> > SFU-style socket is a regular file which has system attribute set and
> > content of the file is one zero byte.
> >
> > These SFU-style sockets are already recognized by Linux SMB client.
> >
> > But Linux SMB client is currently creating new SFU socket in different
> > format which is not compatible with all those SFU applications. Fix this by
> > creating new sockets in correct SFU format which would be recognized by all
> > SFU, SUA, NFS and existing Linux SMB clients.
> >
> > This change affects only creating new sockets when mount option -o sfu is used.
> >
> > Signed-off-by: Pali Rohár <pali@kernel.org>
> > ---
> >  fs/smb/client/smb2ops.c | 7 +++----
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
> > index 4f7eefa7a683..e59fda1b2230 100644
> > --- a/fs/smb/client/smb2ops.c
> > +++ b/fs/smb/client/smb2ops.c
> > @@ -5288,10 +5288,9 @@ int __cifs_sfu_make_node(unsigned int xid, struct inode *inode,
> >                 data = (u8 *)symname_utf16;
> >                 break;
> >         case S_IFSOCK:
> > -               type_len = 8;
> > -               strscpy(type, "LnxSOCK");
> > -               data = (u8 *)&pdev;
> > -               data_len = sizeof(pdev);
> > +               /* SFU socket is system file with one zero byte */
> > +               type_len = 1;
> > +               type[0] = '\0';
> >                 break;
> >         case S_IFIFO:
> >                 type_len = 8;
> > --
> > 2.20.1
> >
> >
> 
> 
> -- 
> Thanks,
> 
> Steve

Re: [PATCH] cifs: Fix support for creating SFU socket

[Pali Rohár]

I have asked Google Gemini AI:

"Is WSL using "LnxSOCK" for storing AF_UNIX socket on NTFS?"

and I got answer:

"No, WSL does not use the tag LnxSOCK to store AF_UNIX sockets on NTFS.
Instead, WSL relies on native Windows features and specific metadata
attributes to handle AF_UNIX sockets on NTFS:
1. The Native Windows afunix.sys Reparse Point
[... longer explanation of reparse points ...]
2. WSL Metadata Extended Attributes
[... longer explanation of $LXMOD and $LXDEV EAs ...]"

This is just an experiment.

I have feeling that with longer AI discussion or formed questions it is
possible to receive from AI everything... from AI hallucination and
wrong answers, or semi-correct answer to fully correct answers.
Sometimes AI answers what people wants to hear...

On Wednesday 08 July 2026 20:35:23 Pali Rohár wrote:
> WSL does not use "LnxSOCK". This looks like an AI hallucination.
> 
> WSL stores data in NTFS reparse points:
>  IO_REPARSE_TAG_AF_UNIX    - 0x80000023
>  IO_REPARSE_TAG_LX_FIFO    - 0x80000024
>  IO_REPARSE_TAG_LX_CHR     - 0x80000025
>  IO_REPARSE_TAG_LX_BLK     - 0x80000026
>  IO_REPARSE_TAG_LX_SYMLINK - 0xA000001D
> And also in NTFS EAs:
>  "$LXUID"
>  "$LXGID"
>  "$LXMOD"
>  "$LXDEV"
> 
> All tests which I have done with WSL's DrvFs resulted in above reparse
> points (or in native Windows symlinks).
> 
> Some sources which confirms those my testing:
> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4
> https://learn.microsoft.com/en-us/windows/wsl/file-permissions
> 
> WSL does not recognize "-o sfu" things at all.
> 
> So here I bet that AI "mixed" SFU and WSL formats and parts together and
> created that hallucinated answer.
> 
> On Wednesday 08 July 2026 08:51:40 Steve French wrote:
> > AI query made it sound like "LnxSOCK" is still used by WSL.  Is this
> > change safe?
> > 
> > "Yes. WSL (particularly WSL 1 and WSL 2 when interacting with NTFS via
> > DrvFs) uses the Lnx* metadata family to represent Linux special file
> > types, including:
> > 
> > LnxSOCK
> > LnxFIFO
> > LnxCHR
> > LnxBLK"
> > 
> > On Tue, Jul 7, 2026 at 4:13 AM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > SFU sockets are natively supported by Interix 3.0 subsystem and also by
> > > later versions. It is part of Microsoft SFU (Windows Services for UNIX) and
> > > Microsoft SUA (Subsystem for UNIX-based Applications). They can be created
> > > and existing (stored on local disk or remote SMB share) can be recognized.
> > >
> > > SFU sockets are recognized also by NFS server included in Windows Server.
> > > Windows NFS server versions since Windows Server 2012 uses new reparse
> > > point format for storing new sockets, but still can recognize this old
> > > format (also in the latest Windows Server 2022 version).
> > >
> > > SFU-style socket is a regular file which has system attribute set and
> > > content of the file is one zero byte.
> > >
> > > These SFU-style sockets are already recognized by Linux SMB client.
> > >
> > > But Linux SMB client is currently creating new SFU socket in different
> > > format which is not compatible with all those SFU applications. Fix this by
> > > creating new sockets in correct SFU format which would be recognized by all
> > > SFU, SUA, NFS and existing Linux SMB clients.
> > >
> > > This change affects only creating new sockets when mount option -o sfu is used.
> > >
> > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > ---
> > >  fs/smb/client/smb2ops.c | 7 +++----
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
> > > index 4f7eefa7a683..e59fda1b2230 100644
> > > --- a/fs/smb/client/smb2ops.c
> > > +++ b/fs/smb/client/smb2ops.c
> > > @@ -5288,10 +5288,9 @@ int __cifs_sfu_make_node(unsigned int xid, struct inode *inode,
> > >                 data = (u8 *)symname_utf16;
> > >                 break;
> > >         case S_IFSOCK:
> > > -               type_len = 8;
> > > -               strscpy(type, "LnxSOCK");
> > > -               data = (u8 *)&pdev;
> > > -               data_len = sizeof(pdev);
> > > +               /* SFU socket is system file with one zero byte */
> > > +               type_len = 1;
> > > +               type[0] = '\0';
> > >                 break;
> > >         case S_IFIFO:
> > >                 type_len = 8;
> > > --
> > > 2.20.1
> > >
> > >
> > 
> > 
> > -- 
> > Thanks,
> > 
> > Steve