Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block/disallow --net=host (host networking) on Mac OS #2716

Open
vhosakot opened this issue Mar 22, 2018 · 27 comments

Comments

@vhosakot
Copy link

commented Mar 22, 2018

Description

https://docs.docker.com/network/network-tutorial-host/ says:

The host networking driver only works on Linux hosts, and is not supported on Docker for Mac

--net=host (host networking) does not work on Mac as it is not supported on Mac. https://forums.docker.com/t/should-docker-run-net-host-work/14215 also says that --net=host is not supported on Mac.

Hence, --net=host should be blocked/disallowed on Mac and an error like --net=host (host networking) is not supported on Mac should be displayed if --net=host is used on Mac. This way, users on Mac know that --net=host is not supported on Mac and will not waste time debugging host networking issues on Mac.

Steps to reproduce the issue:

  1. Run any docker container with --net=host (host networking) on Mac.
    docker run -d --name docker-nginx --net=host -p 80:80 nginx
    
  2. Check if the container's port can be accessed on the Mac host.
    $ curl localhost:80
    curl: (7) Failed to connect to localhost port 80: Connection refused
    

Describe the results you received:

Not able to access the container's port on the Mac host when --net=host is used on Mac.

Describe the results you expected:

$ docker run -d --name docker-nginx --net=host -p 80:80 nginx
ERROR: --net=host (host networking) is not supported on Mac.

Additional information you deem important:

Output of docker version:

$ docker version
Client:
 Version:	17.12.0-ce
 API version:	1.35
 Go version:	go1.9.2
 Git commit:	c97c6d6
 Built:	Wed Dec 27 20:03:51 2017
 OS/Arch:	darwin/amd64

Server:
 Engine:
  Version:	17.12.0-ce
  API version:	1.35 (minimum version 1.12)
  Go version:	go1.9.2
  Git commit:	c97c6d6
  Built:	Wed Dec 27 20:12:29 2017
  OS/Arch:	linux/amd64
  Experimental:	true

Output of docker info:

$ docker info
Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 17.12.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 89623f28b87a6004d4b785663257362d1658a729
runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.60-linuxkit-aufs
Operating System: Docker for Mac
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.952GiB
Name: linuxkit-025000000001
ID: QWYO:HNLA:VPRN:ZTTG:YUNW:CO37:BWYB:L4Z5:CFDY:JC3H:A6DD:RQDM
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 29
 Goroutines: 49
 System Time: 2018-03-22T04:19:59.058199778Z
 EventsListeners: 2
HTTP Proxy: docker.for.mac.http.internal:3128
HTTPS Proxy: docker.for.mac.http.internal:3129
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details:

Mac OS Sierra (version 10.12.6)

@vhosakot

This comment has been minimized.

Copy link
Author

commented Mar 22, 2018

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

@pgayvallet

This comment has been minimized.

Copy link

commented Mar 23, 2018

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.

@vhosakot

This comment has been minimized.

Copy link
Author

commented Mar 23, 2018

@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.

@jakirkham

This comment has been minimized.

Copy link

commented Mar 30, 2018

Looks related to issue ( #68 ).

@zhouxiangxiang

This comment has been minimized.

Copy link

commented Apr 13, 2018

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

@docker-desktop-robot

This comment has been minimized.

Copy link
Collaborator

commented Jul 30, 2018

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

@0x1EE7

This comment has been minimized.

Copy link

commented Aug 3, 2018

/remove-lifecycle stale

@sregger

This comment has been minimized.

Copy link

commented Sep 28, 2018

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 work. 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?

@fgarcia

This comment has been minimized.

Copy link

commented Nov 8, 2018

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

@RobAWilkinson RobAWilkinson referenced this issue Dec 10, 2018
2 of 2 tasks complete
@deftdawg

This comment has been minimized.

Copy link

commented Jan 20, 2019

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.

@vhosakot

This comment has been minimized.

Copy link
Author

commented Jan 21, 2019

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

@deftdawg

This comment has been minimized.

Copy link

commented Jan 22, 2019

@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:

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.

@elver

This comment has been minimized.

Copy link

commented Jan 29, 2019

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.

@henribru henribru referenced this issue Feb 24, 2019
@kazzkiq

This comment has been minimized.

Copy link

commented Mar 12, 2019

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.

@DonGiulio

This comment has been minimized.

Copy link

commented Mar 30, 2019

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

@kojustin

This comment has been minimized.

Copy link

commented Apr 7, 2019

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

@vhosakot

This comment has been minimized.

Copy link
Author

commented Apr 8, 2019

I just wasted a day of time thinking that this worked

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

@mtlott

This comment has been minimized.

Copy link

commented Apr 14, 2019

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.

@dave-dm

This comment has been minimized.

Copy link

commented Apr 25, 2019

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

@danielo515

This comment has been minimized.

Copy link

commented May 22, 2019

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.

@Pasukaru

This comment has been minimized.

Copy link

commented May 27, 2019

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.

@alex-lechner

This comment has been minimized.

Copy link

commented Jun 7, 2019

Can someone of the Docker core development team explain to us what the motivation behind "The --network host functionality will be exclusively for Linux" is? Does it make any sense in terms of UX? Is it considered best practice to release a product and have an exclusive feature for one OS only?

@danielo515

This comment has been minimized.

Copy link

commented Jun 7, 2019

Alex, it is not intentional, it is a OS limitation

@alex-lechner

This comment has been minimized.

Copy link

commented Jun 7, 2019

@danielo515 Okay, thank you for the clarification! Is there any workaround? I need to access 127.0.0.1 from the host machine during Docker build.

EDIT: Never mind. Just found out that you can use http://host.docker.internal:<your-port> to access the host machine instead of http://127.0.0.1:<your-port> during build.

@danielo515

This comment has been minimized.

Copy link

commented Jul 4, 2019

Hey, that was something I didn't know.
Maybe documentation should mention those things instead of pretending this issue does not exist.

@BKJackson

This comment has been minimized.

Copy link

commented Jul 21, 2019

host.docker.internal worked from me.
It was never clear how to use that, but http://host.docker.internal:10000 literally worked from within the container without having to install anything.

@cicorias

This comment has been minimized.

Copy link

commented Aug 23, 2019

has anyone articulated the steps as @pgayvallet alludes to and @vhosakot has asked for? I'd like to see how from the HOST to hit the container - the opposite of host.docker.internal

I don't think it does work according to the docs ---
Use host networking
says

The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.