0

Setup

I have this setup:

  • Windows 10 pro with WSL2 with an Ubuntu 20.04 inside.
  • Inside the Ubuntu, I have a running docker engine that has been working perfectly for over during months, exposing multiple ranges of ports with dozens of images and containers. All perfect.

NFS version 3 and port 111

Today I was playing with an NFS server that must be run on version 3. Port 111 is required in addition to port 2049. The original test was with the image erichough/nfs-server.

I narrowed down to problem to this minimum failing example:

If I do this:

docker run -it --rm -p 111:111 alpine

I get this:

docker: Error response from daemon: driver failed programming external connectivity on endpoint hardcore_kilby (9aa7466f1771c9b5926a00eede289fc1084a12ee09ea2f3deee917c4734034c9): Error starting userland proxy: listen tcp4 0.0.0.0:111: bind: address already in use.

docker on port 111 fails

This suggests that port 111 is used in the host.

To discard it's not something related to the well-known ports range I bound a different port: 112 instead of 111, and it succeeded:

docker on port 112 works

Therefore I thought there's a process listening on port 111.

Nobody on port 111?

This answer on StackOverflow says that Resource monitor can do the job of finding "what process is blocking a port". I launched it, sorted the listing of "Listening ports" by "Port" and....

Oh surprise!!! there's nobody listening on port 111!

Port 111 is not used

Is RPC blocking the port?

The answer below from @Drixter suggests netstat -tapneu to see if the port 111 is blocked by RPC.

On the linux side

netstat -tapneu only works on the linux side of the WSL and reports no port 111 being used.

On the windows side

On the windows side of the WSL (for example via git-bash) the -u option does not exist, the -e option collapses the results to statistics, and the -prequires an extra parameter. So I narrowed down to netstat -tan and also netstat -n.

And none of those reports port 111.

Going deeper

My computer has a fixed IP address in a LAN at 192.168.3.xx. If I specify the IP for the -p option, I can see that port 111 is only used on loopback: 127.0.0.1 (also in the rest of lo addresses like 127.0.0.2, 127.0.0.3, etc) but, instead, the port is free on the LAN address:

See IP address failing

Why?

  • Why is this happening?
  • In my case the IP is static. Should I only expose 111 on the docker container to the host on the LAN address and can never be done in the localhost address?
  • Can it be that the port 111 is used but "not detectable"?
  • Can I see if I do have this RPC thing and its status on the windows side?
Xavi Montero
  • 295
  • 3
  • 16

1 Answers1

0

Are you sure that RPC is not using port 111?

netstat -tapneu | grep 111
Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
Drixter
  • 11
  • 3
  • Edited the question to incorporate this information. No port `111` reported by netstat, neither in the linux side of the WSL, neither in the windows side of the WSL. – Xavi Montero May 09 '21 at 11:24
  • Maybe you need to force to expose 111 from proper 127.0.0.x, I do not know docker, but "listen tcp4 0.0.0.0:111: bind: address already in use" is trying to bind across all interfaces, and one IP is occupied with this port and becuase of this fail. – Drixter May 10 '21 at 12:23
  • As exposed in my latest edition of the question, I already tried `127.0.0.1` as well as other few in the local range, like `127.0.0.2`, `.3`, `.4`... So Definitively "someone" is blocking port `111` on the `lo` interface. As exposed in the latest edit, address `192.168.3.x` has port `111` free. Half of the problem disappears as I can now work on the LAN IP and continue -I think; going to test now- But still the question is "who is locking `111` in `lo` and why? – Xavi Montero May 12 '21 at 09:17
  • Does the telnet work to 111? if something is using that port then connection should be established, then try to check netstat, connection should appear. Could be that Windows is blocking this by any reason, but here I'm guessing. – Drixter May 12 '21 at 19:32