podman: podman --network --host doesn't work on MacOS
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
podman --network host does not work on MacOS
Steps to reproduce the issue:
podman run --rm -it --network host nginxinc/nginx-unprivileged- Open
http://0.0.0.0:8080/on a host web browser.
Describe the results you received: “This site can’t be reached. 0.0.0.0 refused to connect.”
Describe the results you expected: “Welcome to nginx!”
Note: podman run --rm -it -p 8080:8080 nginxinc/nginx-unprivileged works.
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Client: Podman Engine
Version: 4.2.0
API Version: 4.2.0
Go Version: go1.18.5
Built: Thu Aug 11 05:46:05 2022
OS/Arch: darwin/amd64
Server: Podman Engine
Version: 4.2.0
API Version: 4.2.0
Go Version: go1.18.4
Built: Thu Aug 11 23:42:17 2022
OS/Arch: linux/amd64
Output of podman info:
host:
arch: amd64
buildahVersion: 1.27.0
cgroupControllers:
- cpu
- io
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.1.0-2.fc36.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.1.0, commit: '
cpuUtilization:
idlePercent: 96.11
systemPercent: 1.45
userPercent: 2.44
cpus: 1
distribution:
distribution: fedora
variant: coreos
version: "36"
eventLogger: journald
hostname: localhost.localdomain
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 1000000
uidmap:
- container_id: 0
host_id: 501
size: 1
- container_id: 1
host_id: 100000
size: 1000000
kernel: 5.18.18-200.fc36.x86_64
linkmode: dynamic
logDriver: journald
memFree: 661733376
memTotal: 2064896000
networkBackend: netavark
ociRuntime:
name: crun
package: crun-1.5-1.fc36.x86_64
path: /usr/bin/crun
version: |-
crun version 1.5
commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
os: linux
remoteSocket:
exists: true
path: /run/user/501/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: true
serviceIsRemote: true
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
version: |-
slirp4netns version 1.2.0-beta.0
commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
libslirp: 4.6.1
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.3
swapFree: 0
swapTotal: 0
uptime: 1h 30m 46.00s (Approximately 0.04 days)
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
volume:
- local
registries:
search:
- docker.io
store:
configFile: /var/home/core/.config/containers/storage.conf
containerStore:
number: 1
paused: 0
running: 0
stopped: 1
graphDriverName: overlay
graphOptions: {}
graphRoot: /var/home/core/.local/share/containers/storage
graphRootAllocated: 106825756672
graphRootUsed: 4620713984
graphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 6
runRoot: /run/user/501/containers
volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
APIVersion: 4.2.0
Built: 1660228937
BuiltTime: Thu Aug 11 23:42:17 2022
GitCommit: ""
GoVersion: go1.18.4
Os: linux
OsArch: linux/amd64
Version: 4.2.0
Package info (e.g. output of rpm -q podman or apt list podman):
$ brew info podman
==> podman: stable 4.2.0 (bottled), HEAD
Tool for managing OCI containers and pods
https://podman.io/
/usr/local/Cellar/podman/4.2.0 (178 files, 48.5MB) *
Poured from bottle on 2022-09-07 at 13:41:20
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/podman.rb
License: Apache-2.0
==> Dependencies
Build: go-md2man ✘, go@1.18 ✘
Required: qemu ✔
==> Options
--HEAD
Install HEAD version
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d
==> Analytics
install: 24,749 (30 days), 60,086 (90 days), 198,346 (365 days)
install-on-request: 24,099 (30 days), 59,090 (90 days), 197,229 (365 days)
build-error: 16 (30 days)
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.): Macbook Pro 2019
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 7
- Comments: 17 (7 by maintainers)
Hi @Luap99. That link is greatly useful. I came to this thread because I had this exact bug, so I don’t think this is a general question, more discussion about this actual bug, so others can help understand the issue.
In fact the gvisor-tap-vsock repo has some inspiration as to a work-around so at least I can ‘sort-of’ use net host, even if there’s a bit of futzing.
Hack to at least get some ports forwarded
Gvproxy is exposing a ssh port, so we can be cheeky and use SSH port forwarding. You can do this in gvproxy too, but I am not 100% sure it is safe to connect to that auto-generated sock that gvproxy is currently using.
So we can see my SSH is on port 55816. Using root, with an identity file. Thus I can tweak to
Which lets me at least expose the ports needed by hand. This is obviously not ‘exactly’ the same as net=host, but could be helpful for someone who needs to use net=host, and doesn’t want to spin up a whole seperate VM stack to do so. Which was my case.
There is also probably a much better way speaking to the gvsock socket directly, but I think Podman is only spinning up a tcp port for ssh at the moment… which makes sense, but perhaps this is configurable
Since we use user space networking for the VM it is impossible to access the VM via ip address from the host. You have to forward ports to access it.
From within the VM you can use
host.containers.internalto access the host.