Repository navigation
Windows/WSL AF_UNIX Interop doesn't work in WSL2 #5961
Description
Activity
therealkenc Thanks for pointing me to the comment. I've seen the issue but didn't go through all the comments as the issue itself was limited to abstract addresses.
I'm no expert but I see no obvious reason why the enlightened WSL kernel shouldn't be able to communicate with the host and
afunix.syswould handle these files on the host too.Since I'm interested in existing binaries, using
AF_INET(or anything else that requires source change) doesn't help me. I used Python just because it was easier to reproduce. Even if it did, I opened this issue for the broader issue and not just to solve my problem with this or that program.At one point I even considered a temporary solution of hooking both sides and using
AF_HYPERVas the underlying transport, but it requires some work and by the time I'm done you might just implement the real deal.Reacted by rupor, Ivan Pashin and Tom Tanconioh did you get a chance to enable AF_UNIX in WSL2 ?
conioh did you get a chance to enable AF_UNIX in WSL2 ?
Ivan Pashin (@ivan046), unfortunately I haven't. It's not a matter of simply enabling something. I'd have to multiplex multiple UNIX socket connections over a VSOCK connection. It's not that simple and it wasn't important enough yet. For specific cases there may be simple workarounds like using netcat/socat.
- added a commit that references this issue
on May 28, 2021 Now that the official way to install WSL means install only WSL2, it is a good time to ask again support for AF_UNIX interop with WSL2.
Sure, WSL1 isn't deprecated and "we currently have no plans to deprecate WSL 1", but we all know what that means:
There's no reason to treat WSL2 as a second-class citizen, especially since Microsoft is promoting it so much and since implementing it is basically the same as the current implementation, just with a different enlightenment on the Linux kernel side.
Reacted by wych(witch), Danila, Edouard Shamis, Jesse Wertheim, Ajay Mehta, Arun, Antoine, Aankhen, Qyriad, Mike Iversen and 29 moreAnother 2 years later...
Reacted by carschandler, Rishov Sarkar, Misato Kano, Sergei Dobrikov, Rodrigo Nossal, Nithin M.K., Peter Saan, Nikolay D Khodyunya, Nebuchadrezzar and Artur FaizullinIsn't this fixed now..see https://github.com/microsoft/WSL/releases/tag/2.0.14 ?
Latest Version i can get from the store is 2.0.9.0
psh ❯ wsl -v -l WSL-Version: 2.0.9.0 Kernelversion: 5.15.133.1-1 WSLg-Version: 1.0.59 MSRDC-Version: 1.2.4677 Direct3D-Version: 1.611.1-81528511 DXCore-Version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows-Version: 10.0.22631.3155 psh ❯ wsl zsh ❯ python3 -c "import socket; sock = socket.socket(socket.AF_UNIX); sock.bind('/mnt/c/test.sock')" Traceback (most recent call last): File "<string>", line 1, in <module> OSError: [Errno 95] Operation not supportedAre there any recommendations to this ? Some mitigations ? I am trying to relay unix sockets to named pipes, but I have to spawn an additional program and use its stdin and stdout, even that is difficult.
Reacted by Sebastian Studniczek- added a commit that references this issue
on Jul 5, 2026
Environment
Steps to reproduce
python3 -c "import socket; sock = socket.socket(socket.AF_UNIX); sock.bind('/mnt/d/test.sock')"python_unix_socket.strace.txt
WSL logs:
https://aka.ms/AA9q0yn
Expected behavior
As In WSL1, I expect no error and the
D:\test.sockfile created:Actual behavior
Error and no file created: