Opened this issue per suggestion in moby/moby#36666 (comment).

As you probably know, on D4M, docker is running inside a VM.
So "-net=host is not working" is subject to interpretation : it's working in the fact that the container uses the VM network, it's not in the fact that the VM network is not the host network.

However, in some use case, the actual behaviour is the one expected. That's why we just can't simply disable the whole option on D4D, as it would break for some of our users using it.

The solution is probably more on documentation than on blocking the option.

@pgayvallet Thanks for the info. Yes, when --net=host is used on a Mac, good documentation and an example how to access the container's port on the VM network inside the VM on a Mac would be very helpful. The documentation could also include the step to setup port-forwarding on the Mac to the VM's port so that the container's port can be accessed directly from the Mac when --net=host is used.

Also, can you send me steps to access the container's port on the VM network inside the VM on Mac when --net=host is used? I was not able to find them online.

Looks related to issue ( #68 ).

I have spend days for debugging network issues on mac.
And now I found this issue.
It should post some information tell user it's not supported on mac

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

/remove-lifecycle stale

As you probably know, on D4M, docker is running inside a VM.

Had no idea this was the case until I started searching for why

docker --net=host

was not working. This is a confusing User Experience and should be improved. Appreciate there is room for interpretation. But common sense usage should win out. I don't think that's currently the case.

Can this issue be re-opened?

I always thought that there should be another option like --net=host-virtual or something like that. Then host would work only in Linux and host-virtual in non Linux environments. Failing on non supported option would encourage users to read the manual, not to explore github issues

I've probably just wasted 3 days trying to get 2 different applications (home-assistant and mythtv) that will never work without a real implementation of host network because I had guessed given that -p ports are published that the host networking should also work...

Please don't tell me host networking does work but only for the VM, host networking means binding directly to the physical network / physical NIC, the VM doesn't do that and I can't even figure out how to access the VM (docker-machine doesn't seem to do anything on OSX)...

I can't imagine how much time people have collectively wasted troubleshooting this!

Invoking docker with --net=host should fail with an ERROR when started from non-linux OSes.

Very happy to see this issue is helping many people! 😄

@vhosakot This issue isn't really helping anyone... 😉

But anyway... For those struggling with this problem here's something that will actually help; I've been able to work around 'docker for mac's limitation by the following:

• uninstall 'Docker for Mac'
• install 'Docker Toolbox' for mac
• create the docker machine VM
• run this script which adds a bridged NIC to virtualbox's docker VM (https://raw.githubusercontent.com/blueimp/shell-scripts/df2eaf79ad7935bfb4b6d5834895d4912d6df4ea/bin/docker-machine-bridge.sh)
• capture the IP address by rerunning the script a second time (export CONTAINER_IP=$(docker-machine-bridge.sh))
• start containers with --net=host
• connect to the container at the IP address captured

Since using a Vbox bridged nic puts the docker-machine host VM directly on the network at it's own IP, network=host works from there at it's new IP.

This is the most absurdly simple "bug" I've seen where fixing it should take a developer literally minutes, but nobody has done it for over half a year.

Users should at least be warned when trying to use networking in Docker since it's capped in macOS and Windows.

At least a message like:

[Docker Networking]:
We detected you're fiddling with networking, but sadly it's only supported in Linux.

would be enough.

Also, it's 2019. Honestly, buy some macs and PCs and enforce them on your team so they actually see the issues we're having. That would do wonders for QA.

There's indeed some lack of documentation here,

is there a way I can connect to the docker virtual machine so that I could check things before I deploy to prod (which is a Linux system)?

I just wasted a day of time thinking that this worked the same that it does on Linux.

I just wasted a day of time thinking that this worked

@kojustin Wasting just a day on this issue is very productive lol 😉

And I just wasted 2 hours on this. So I guess I am more productive than the last guy.

But Really???!!???

I don't work with docker day in and out. There should be error or warning message on D4M that reminds about these nuances. My use case is usually picking up a working compose stack and bringing it locally to a Mac to make some tweaks. A little warning that says this one won't work here would have been nice.

And I just wasted 2 hours on this. So I guess I am more productive than the last guy.

But Really???!!???

I don't work with docker day in and out. There should be error or warning message on D4M that reminds about these nuances. My use case is usually picking up a working compose stack and bringing it locally to a Mac to make some tweaks. A little warning that says this one won't work here would have been nice.

same

Ok, It is very disappointing that this does not work, but I can understand it.
What it is very frustrating is to waste time thinking that the command you just launched works but in reality it does not.
At least a warning is required, please.

I also spent a few hours on this. Once you know why, it makes sense.

However, it should definitely throw an error and not continue without any message whatsoever, making users (including me) think the command will work.

@nicks on the scene! Thanks!

Very excited to hear there's some motion in the ocean on this! Subscribe to the thread, good luck brave devs!

What a sink of dev time for not implementing a warning, which would take 5 minutes to someone experienced with the docker for mac codebase... I was trapped like so many other people in this thread...

At this point is getting comical

fixed all my sins all this while but this issue is still open.

Is this a payed feature ? LOOL

I would actually pay for this (a solution, not a warning) ;-)

Lucky to learn it now after a few days configuring a platform install. Cannot do as planned, any plan to resolve this ? 😆

During these five years I've turned 50, became a grandfather, survived COVID, and bought a house. Anyone else care to share their stories while the issue is being actively resolved? :-)

During these five years I've turned 50, became a grandfather, survived COVID, and bought a house. Anyone else care to share their stories while the issue is being actively resolved? :-)

It took me a bit less to understand this comment is outdated: #2716 (comment)

I have hit this error: https://forums.virtualbox.org/viewtopic.php?f=8&t=107680

Stderr: 0%...NS_ERROR_FAILURE
VBoxManage: error: Failed to create the host-only adapter
VBoxManage: error: Failed to execute '/Applications/VirtualBox.app/Contents/MacOS/VBoxNetAdpCtl add 2>&1' - exit status: 34304
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component HostNetworkInterfaceWrap, interface IHostNetworkInterface
VBoxManage: error: Context: "RTEXITCODE handleCreate(HandlerArg *)" at line 105 of file VBoxManageHostonly.cpp

So there's definitely no way now to run a container with host network ?

The only way I managed to get it to work is to run docker using devcontainers which somehow makes things work out. But this is ridiculous. I understand things aren't simple and you've had to deal with a lot of mac issues what with all the Apple Silicon changes.

But it can't honestly take 5 years to either:

• add an error message on non-linux machines
• Find a solution to make this work on macs

Docker is meant to be a solution to standardize how developers collaborate and run projects on whichever platform they want. But in reality that isn't the case because some options just won't work on other systems and rather than say so directly and reject the command you prefer to have your users rip their hair out of frustration debugging known issues.

Making Host OS networking work on MacOS is tracked here: docker/roadmap#238

Blocking this with an error message is not really on the table, because there are lots of legitimate use-cases for binding to the Host VM network (rather than the Host OS network). For example, Telepresence uses --net=host and wants to bind to the VM network, here's a good post on it: https://www.getambassador.io/kubernetes-learning-center/telepresence-docker-extension

There's been some discussion about making it a warning or having a way to disambiguate like --net=host-os or --net=host-vm, but there are concerns about portability.

There should've been a warning when Docker for Mac was first released. At least the command line docker command should warn something about it, even if the Docker for Mac GUI people can't figure out how to handle it.

Besides the 100 or so folks who've found this thread and commented, think of all the other people who give up trying to run a tutorial or a product installation on mac that includes --net=host because it appears to be silently broken.

It would take what to implement a warning? An OS check (docker mac cli), a docker version check (< whatever version will eventually implement it) and a printf?

Blocking this with an error message is not really on the table, because there are lots of legitimate use-cases for binding to the Host VM network (rather than the Host OS network). For example, Telepresence uses --net=host and wants to bind to the VM network, here's a good post on it: https://www.getambassador.io/kubernetes-learning-center/telepresence-docker-extension

There's been some discussion about making it a warning or having a way to disambiguate like --net=host-os or --net=host-vm, but there are concerns about portability.

cc @davidlopezre

Happy 5th Birthday to this issue 🍰

yay, happy 5th Birthday all! 🍰

Happy birthday for three days ago :( If I had the skill and/or time I would try and fix this, but alas I don't. I hope that one day this issue gets resolved by a majestic computer wizard.

So, what are the workarounds for now?

If you want docker containers to be able to access a specific application running on say, 127.0.0.1:3000, one solution is to run a proxy inside the container to the host.docker.internal network bridge. You can do so with a utility called socat.

An example so the docker container can access 127.0.0.1:3000 on your machine:

apt-get update && apt-get install -y socat
socat TCP-LISTEN:3000,fork TCP:host.docker.internal:3000

I'm almost sure the entire team unsubscribed from this Issue, thankfully I got to find out it doesn't work by using Docker Desktop and "lsof" seeing there was no port open, we're near the 6th birthday!

@danielo515Ok, obrigado pelo esclarecimento! Existe alguma solução alternativa? Preciso acessar 127.0.0.1da máquina host durante a construção do Docker.

EDITAR: Não importa. Acabei de descobrir que você pode usar http://host.docker.internal:<your-port>para acessar a máquina host em vez de http://127.0.0.1:<your-port>durante a construção.

thank you

We added a "host networking" beta feature to Docker Desktop 4.29. You can find more details on this page: https://docs.docker.com/network/drivers/host/#docker-desktop.

Let me close this ticket as 'won't fix'.