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:

  1. podman run --rm -it --network host nginxinc/nginx-unprivileged
  2. 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)

Most upvoted comments

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.

  501 22429     1   0  8:27pm ??         0:05.96 /opt/homebrew/Cellar/podman/4.3.0/libexec/podman/gvproxy -listen-qemu unix:///var/folders/c1/vbnsmxm507n4tymmlvzvx45r0000gn/T/podman/qmp_podman-machine-default.sock -pid-file /var/folders/c1/vbnsmxm507n4tymmlvzvx45r0000gn/T/podman/podman-machine-default_proxy.pid -ssh-port 55816 -forward-sock /Users/beautrepp/.local/share/containers/podman/machine/podman-machine-default/podman.sock -forward-dest /run/podman/podman.sock -forward-user root -forward-identity /Users/beautrepp/.ssh/podman-machine-default

So we can see my SSH is on port 55816. Using root, with an identity file. Thus I can tweak to

ssh root@127.0.0.1 -p 55816 -i /Users/beautrepp/.ssh/podman-machine-default -v -L 4646:127.0.0.1:4646

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.internal to access the host.