skip to Main Content

There are a few similar questions for this issue but I don’t think this exact one.

All of my local dev containers were running fine yesterday on their respective :80 and :443 ports. This was both starting them using docker-compose and also in debug mode from Visual Studio.

All of a sudden this morning I’m getting the following error:

Unhandled exception. System.IO.IOException: Failed to bind to address http://[::]:80: address already in use.

FYI, all of these exact same containers and config run at this moment on my other machine (i.e. laptop) so it is a machine specific issue.

I’m using WSL2 and the latest version of Docker Desktop (using the WSL2 engine).

I did do the latest Windows cumulative update yesterday but after doing that things were still running fine.

I’ve run the following command to see if anything is using port 80:

sudo lsof -i :80

And there are no results (I assume this means nothing is running on the port).

I have run the following command to check that no other containers are running too:

docker ps

I’ve stopped and started and restarted again everything from docker to my whole machine.

My docker override file has the following ASP setting:

- ASPNETCORE_URLS=https://+:443;http://+:80

Unsurprisingly removing the http://+:80 solves my issue and my container starts up using its 443 port.

I’m at a complete loss as to what could be causing this and whilst I can happily just use the :443 ports it would be good to figure out what is going on and solve it.

3

Answers


  1. EDIT: disregard my answer, since the problem came back.

    I ran into this problem and resolved it by upgrading to version 4.18.0 (104112) and then running "Reset to factory defaults". I’m not sure if simply upgrading would have fixed the bug or not, since I didn’t try each step independently. Note that there’s no mention of this bug being fixed in the release notes for the new version.

    Good luck!

    Login or Signup to reply.
  2. I had the same issue on Docker Desktop 4.13.0 and 4.18.0.
    In my case the issue appeared due to automatic upgrade of WSL to version 1.2.0.

    Checking WSL Releases, I could see that this release is now marked as pre-release, which makes me believe that it was once set as latest but later was demoted to pre-release.

    Check your version of WSL:

    wsl --version
    

    I have fixed the issue after upgrading to the latest pre-release version of WSL using command:

    wsl --update --pre-release
    

    This will upgrade you to the latest pre-release version, however it is worth checking what stable version is currently available. Possibly the issue is fixed and new stable version is already released.

    Login or Signup to reply.
  3. Local IIS on my host machine was using port 80 and I temporarily solved the problem (until the root cause of the issue gets fixed) by changing the default Web Site’s port to 81 as below:

    enter image description here

    Edit: Updating WSL version to the latest version (1.2.5 currently) fixed the issue for me. I updated it by opening WSL app’s installation info from Microsoft Store and clicking on the "Update" button. It should be noted that Microsoft Store doesn’t distinguish pre-release versions from the stable versions as of now so it will auto-update the applications to their pre-release versions and that was the cause of this bug actually. Updating the app from Microsoft Store will again update it to another pre-release version but I’ll stick to Microsoft Store installation for a while hoping that they change this behavior..

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search