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 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: (also in the rest of lo addresses like,, etc) but, instead, the port is free on the LAN address:

See IP address failing


  • 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?

Are you sure that RPC is not using port 111?

netstat -tapneu | grep 111
  • 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 9 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 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 at 12:23
  • As exposed in my latest edition of the question, I already tried as well as other few in the local range, like, .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 at 9: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 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.