Update to 4.18.0 removed 127.0.0.1 host.docker.internal from hosts file on windows

[ILucasI]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID:

Actual behavior

After the update to 4.18.0 the entry for 127.0.0.1 host.docker.internal was removed from my hosts file.

Expected behavior

The update should not remove this entry.

Information

• Windows Version: 22H2
• Docker Desktop Version: 4.18.0 (104112)
• WSL2 or Hyper-V backend? WSL2
• Are you running inside a virtualized Windows e.g. on a cloud server or a VM: no

Steps to reproduce the behavior

1. Update to latest version

[jeffdafoe]

Thanks, Docker wouldn't start for me after the update, adding the hosts entry back in fixed it.

[magarzon]

Thanks, a few hours wasted (who I have to invoice for this?) trying to find why my containers running without port mapping (or with port mapping configured from an application like lando) wasn't working: adding rules to the firewall, updating/upgrading everything,... trying a thousand combinations...

[memetrusidovski]

can anyone tell me how to try this fix. i've tried deleting all antivirus too from my computer and still nothing. tried reinstalling everything and still nothing. docker can eventually get running in WSL and pull images but docker desktop doesnt work at all. and when i close WSL docker just crashes. thanks!(been trying to fix this for days. really missing my macbook lol)

[memetrusidovski]

System.InvalidOperationException:
distro stopped unexpectedly
at Docker.Engines.LinuxkitDaemonStartup.d__5.MoveNext() in C:\workspaces\PR-19568\src\github.com\docker\pinata\win\src\Docker.Engines\LinuxkitDaemonStartup.cs:line 60
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Docker.Engines.WSL2.LinuxWSL2Engine.d__26.MoveNext() in C:\workspaces\PR-19568\src\github.com\docker\pinata\win\src\Docker.Engines\WSL2\LinuxWSL2Engine.cs:line 170
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Docker.ApiServices.StateMachines.TaskExtensions.d__0.MoveNext() in C:\workspaces\PR-19568\src\github.com\docker\pinata\win\src\Docker.ApiServices\StateMachines\TaskExtensions.cs:line 29
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Docker.ApiServices.StateMachines.StartTransition.d__5.MoveNext() in C:\workspaces\PR-19568\src\github.com\docker\pinata\win\src\Docker.ApiServices\StateMachines\StartTransition.cs:line 67
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Docker.ApiServices.StateMachines.StartTransition.d__5.MoveNext() in C:\workspaces\PR-19568\src\github.com\docker\pinata\win\src\Docker.ApiServices\StateMachines\StartTransition.cs:line 92
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Docker.ApiServices.StateMachines.EngineStateMachine.d__14.MoveNext() in C:\workspaces\PR-19568\src\github.com\docker\pinata\win\src\Docker.ApiServices\StateMachines\EngineStateMachine.cs:line 69
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Docker.Engines.Engines.d__22.MoveNext() in C:\workspaces\PR-19568\src\github.com\docker\pinata\win\src\Docker.Engines\Engines.cs:line 106

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Docker.Engines.Engines.d__22.MoveNext() in C:\workspaces\PR-19568\src\github.com\docker\pinata\win\src\Docker.Engines\Engines.cs:line 106

[SJRM78]

Thanks, Docker wouldn't start for me after the update, adding the hosts entry back in fixed it.

I had same problem yesterday.
It also fixed after adding that entry to hosts file.

127.0.0.1 host.docker.internal

however, today i restarted the laptop, and problem is happening again.
I validated that entry is still in the hosts file.

I confirmed i can ping host.docker.internal from both Windows cmd and wsl ubuntu terminal.

EDIT:
I downgraded to version 4.17.1 and it works.
The difference is these lines added to the hosts file by Docker Desktop

# Added by Docker Desktop
192.168.100.4 host.docker.internal
192.168.100.4 gateway.docker.internal
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section

[elapuyade]

Hi,
Could you please clarify whether you need to resolve host.docker.internal from a container only? Or you need to resolve it from the host itself too?

[ILucasI]

Hi,
Could you please clarify whether you need to resolve host.docker.internal from a container only? Or you need to resolve it from the host itself too?

Hi,
I need it on both sides. We have some microservices that are running in Docker and communicating with each other. If we start one of them through IDE for development the services must reach each other and therefore the services in docker must bei able to reach the one running in IDE and vice versa.

[davidalbertonogueira]

I don't know if it is related, but upgrading for 4.18 broke docker for me. Needed to revert (went back to 4.16 which I remembered it worked).

This was the error message:

 => ERROR [internal] load metadata for docker.io/continuumio/anaconda3:latest                                                                                                                                                                                                      0.0s
------
 > [internal] load metadata for docker.io/continuumio/anaconda3:latest:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to do request: Head "https://registry-1.docker.io/v2/continuumio/anaconda3/manifests/latest": proxyconnect tcp: dial tcp 192.168.65.7:3128: connect: connection refused
[+] Running 0/1
 ⠿ test-cashback-spark Error                                                                                                                                                                                                                                                       1.8s
Error response from daemon: Get "https://registry-1.docker.io/v2/": proxyconnect tcp: dial tcp 192.168.65.7:3128: connect: connection refused

[magarzon]

Another issue for me: docker run doesn't expose any port if no port mapping is set.

I mean, if you execute this example: docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql

The container is up, but the default port for mysql (3306) is not mapped, so I can't access to that mysql (although the port seems to be busy if the container is up, because I can't map any other service to that port)

If I execute docker run -p 3306:3306 --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql, it works

[elapuyade]

I need it on both sides. We have some microservices that are running in Docker and communicating with each other. If we start one of them through IDE for development the services must reach each other and therefore the services in docker must bei able to reach the one running in IDE and vice versa.

@ILucasI
I don't understand something.

You run an IDE on the host. You run micro services in containers.
Micro services will resolve host.docker.internal to the host IP and connect into the IDE.
But if the IDE resolves host.docker.internal it also just gets the host IP, not that of anything in a container.

What do you mean by "vice versa"? What, on your host, needs to resolve host.docker.internal and why?

[ILucasI]

I need it on both sides. We have some microservices that are running in Docker and communicating with each other. If we start one of them through IDE for development the services must reach each other and therefore the services in docker must bei able to reach the one running in IDE and vice versa.

@ILucasI I don't understand something.

You run an IDE on the host. You run micro services in containers. Micro services will resolve host.docker.internal to the host IP and connect into the IDE. But if the IDE resolves host.docker.internal it also just gets the host IP, not that of anything in a container.

What do you mean by "vice versa"? What, on your host, needs to resolve host.docker.internal and why?

The service running in my IDE needs to resolve host.docker.internal too. In order to connect to the services running in docker and to preserve the origin.

We have a keycloak server running inside docker which is responsible for authentification. if we want to communicate with a backend service we need a token first. We can get this from KC via localhost or host.docker.internal (or every other name that resolves to 127.0.0.1. KC will write the origin from which it was called into the token and the services will check that issuer claim too. And that check is the reason why we need host.docker.internal. If this name dosen't resolve to 127.0.0.1 from both sides this check will fail because issuer in the JWT and the hostname of the issuer don't match.

[elapuyade]

Thanks all for your explanations. We are looking into it and will try to get those names back into the hosts file in next version.