"Ports are not available" for dapr_scheduler in Windows using Docker

[boclifton-MSFT]

Expected Behavior

Scheduler container starts as expected.

Actual Behavior

dapr init gives a Docker error:

PS C:\Users\boclifton> dapr init
Making the jump to hyperspace...
Container images will be pulled from Docker Hub
Installing runtime version 1.14.4
Downloading binaries and setting up components...
docker: Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:52379 -> 0.0.0.0:0: listen tcp4 0.0.0.0:52379: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

Docker Desktop reports this error: (HTTP code 500) server error - Ports are not available: exposing port TCP 0.0.0.0:52379 -> 0.0.0.0:0: listen tcp4 0.0.0.0:52379: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

Steps to Reproduce the Problem

Started from a fresh installation and followed the instructions in Initialize Dapr in your local environment.

Release Note

RELEASE NOTE:
FIX: Docker port issue resolved with default dapr_scheduler port

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[dapr-bot]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

[deanberris]

This is still a bug, any update on how to work around or fix this? @boclifton-MSFT

[antontroshin]

Hello @boclifton-MSFT and @deanberris
I, occasionally, came across the same problem on Windows. I did some research and reading and here's my conclusion.

The error An attempt was made to access a socket in a way forbidden by its access permissions can happen when ports have been reserved by some Windows components, from reading around the internet, the most prominent are Hyper-V, Docker, and WSL, but not exclusively.
This command displays the TCP port ranges that are currently excluded (reserved for system programs) and they won't be available to user programs.
netsh int ipv4 show excludedportrange protocol=tcp
And then use netstat -noa to find which application/service using the port.
In some cases, the suggested fix is to restart Windows NAT, but that does not guarantee that the problem will be solved and is simply a variation of restarting a PC.
Sources:

• https://stackoverflow.com/questions/58216537/what-is-administered-port-exclusions-in-windows-10
• Unable to bind ports: Docker-for-Windows & Hyper-V excluding but not using important port ranges docker/for-win#3171 (comment)

A more permanent solution would be modifying the dynamic port reservation range.

BUT I STRONGLY SUGGEST AGAINST IT, ESPECIALLY ON PRODUCTION SYSTEMS

WARNING: Modifying system defaults is solely the responsibility of the user and I cannot guarantee the results or be responsible for any harm caused to the system.

You can read more on this topic here
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/default-dynamic-port-range-tcpip-chang

In my case, I've modified the dynamic limit above the default Dapr port ranges on Windows.
View current dynamic port range: netsh int ipv4 show dynamicport tcp
Modify dynamic port range: netsh int ipv4 set dynamicport tcp start=59152 num=6384
WARNING This command will reduce by 10000 the number of dynamic ports from the default range start=49152 num 16384
Again, will urge you to exercise caution.

[deanberris]

Thanks for the suggestion. Could this be something that can be fixed in Dapr where it can pick from a set of ports, instead of using a single static port?

[BADF00D]

Would be nice, if there will be a fix in DAPR. Restart doesn't solve the problem for me. Limiting the dynamic port range is an option, but not a good one.

[WhitWaldo]

Just chiming in with my workaround. From an elevated terminal, run net stop winnat, then dapr init and finally net start winnat.

I've added this as a workaround to the troubleshooting docs in an open PR.