Bash on Ubuntu on Windows - bind unix socket failed.

[sinojelly]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [版本 10.0.15063]

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)
  I want to bind socket in my program , compile and run it, it complains "bind: Operation not permitted".
  But the same program run ok on Ubuntu.

main.cpp content is:

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>

#define SOCK_PATH "echo_socket"

int main(void)
{
	int s, s2, t, len;
	struct sockaddr_un local, remote;
	char str[100];

	if ((s = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
		perror("socket");
		exit(1);
	}

	local.sun_family = AF_UNIX;
	strcpy(local.sun_path, SOCK_PATH);
	unlink(local.sun_path);
	len = strlen(local.sun_path) + sizeof(local.sun_family);
	if (bind(s, (struct sockaddr *)&local, len) == -1) {
	    perror("bind");
		exit(1);
	}
	return 0;
}

CMakeLists.txt content is:

cmake_minimum_required (VERSION 2.6)
project (main)
add_executable(main main.cpp)

commands:
cd socket-test
cmake .
make
./main

• What's wrong / what should be happening instead:
  It should not complains "bind: Operation not permitted".

• Strace of the failing command, if applicable: (If <cmd> is failing, then run strace -o strace.txt -ff <cmd>, and post the strace.txt output here)
  See attached files.

strace.txt

[sunjoong]

@sinojelly - I don't have cmake, so compiled it with g++ and ran it; it made a file named echo_socket but print no messages, even bind: Operation not permitted or socket or bind. I inserted printf () before return 0 and that was printed. I mean I could not reproduce yours.

And then... I compiled test code from http://osr507doc.sco.com/es/netguide/dusockT.code_samples.html . It looked working well too.

Hmm... Do you use anti-virus? Sometimes.... anti-virus makes strange things in WSL.

[sunilmut]

@sinojelly - Thanks for reporting the issue and the detailed repro steps. I was able to repro the issue. The problem seems to be in the bind operation of unix sockets in DrvFs i.e /mnt/<dir>. I will look further to see what is going on. But, this should work fine in LxFs i.e anywhere in your home directory. So, if you cd ~, copy the program there and run it, it should run fine. This is just a workaround, and, I understand that this is a bug nonetheless.

@sunjoong - Thanks for chiming in. The reason you were not able tor repro it is probably because you were trying it in 'LxFS. If you try it under /mnt/<c, d, etc..>`, you should be able to repro it. Also, just FYI, that unix domain sockets have nothing to do with Anti-virus or firewalls.

[sunjoong]

@sinojelly - I did not notice that's happened in /mnt/<dir>. Another workaround; changing SOCK_PATH definition to #define SOCK_PATH "/tmp/echo_socket" could avoid that, you know.

[therealkenc]

The problem seems to be in the bind operation of unix sockets in DrvFs i.e /mnt/<dir>

Marking this as a bug is cool, but are you really considering supporting this? I mean that would be balls, but... really?? You've got the same problem with say block/character device inodes (mknod(1)). Or named pipes (mkfifo(1)). Support would would be interesting to be sure, but you gotta ask, what's the use case... That is, absent actually supporting those things in win32-land.

[sunilmut]

@therealkenc - The underlying issue here is that DrvFs does not has support for metadata. There are other scenarios (some, you have listed) that are blocked behind the same problem. If we want to provide compatibility for running Linux apps on DrvFS, this will be needed.

[therealkenc]

Awesome. I didn't know that was even on the table. Notwithstanding no-promises on timeframe caveats of course.

[mattoni]

I'm running Docker on Windows (by connecting the linux version to the windows daemon), and one of the containers I'm trying to run needs to create a unix socket. It's running into the same error, so I'm assuming the containers are being run on DrvFs. Is there a workaround or way for me to set the containers to run in a way that it can create unix sockets?

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!