podman: podman run returns error "unexpected end of JSON input"

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

When I try to run a container using podman v3.4.0 on macOS 11.6 x86_64, I get the following issue:

$ podman run hello-world 
Resolved "hello-world" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/hello-world:latest...
Getting image source signatures
Copying blob sha256:2db29710123e3e53a794f2694094b9b4338aa9ee5c40b930cb8063a1be392c54
Copying blob sha256:2db29710123e3e53a794f2694094b9b4338aa9ee5c40b930cb8063a1be392c54
Copying config sha256:feb5d9fea6a5e9606aa995e879d862b825965ba48de054caab5ef356dc6b3412
Writing manifest to image destination
Storing signatures
Error: error preparing container 4c55ffed4a30a40b87a20cffc862661c8755c81d766b6cac45e0ee680d64f2fe for attach: error configuring network namespace for container 4c55ffed4a30a40b87a20cffc862661c8755c81d766b6cac45e0ee680d64f2fe: error adding pod busy_darwin_busy_darwin to CNI network "podman": unexpected end of JSON input

Running a container fails for podman remote as well as when I ssh into the machine and execute the command with the same error.

Describe the results you received:

Running a container fails with the error message:

Error: error preparing container 4c55ffed4a30a40b87a20cffc862661c8755c81d766b6cac45e0ee680d64f2fe for attach: error configuring network namespace for container 4c55ffed4a30a40b87a20cffc862661c8755c81d766b6cac45e0ee680d64f2fe: error adding pod busy_darwin_busy_darwin to CNI network "podman": unexpected end of JSON input

Describe the results you expected: The container starts.

Additional information you deem important (e.g. issue happens only occasionally):

Looking at the symptom this looks similar to containers/podman#11452 and containers/podman#11235, but I already checked and I do not have a ~/.docker directory anymore.

$ podman network inspect podman

Result

[
    {
        "cniVersion": "0.4.0",
        "name": "podman",
        "plugins": [
            {
                "bridge": "cni-podman0",
                "hairpinMode": true,
                "ipMasq": true,
                "ipam": {
                    "ranges": [
                        [
                            {
                                "gateway": "10.88.0.1",
                                "subnet": "10.88.0.0/16"
                            }
                        ]
                    ],
                    "routes": [
                        {
                            "dst": "0.0.0.0/0"
                        }
                    ],
                    "type": "host-local"
                },
                "isGateway": true,
                "type": "bridge"
            },
            {
                "capabilities": {
                    "portMappings": true
                },
                "type": "podman-machine"
            },
            {
                "capabilities": {
                    "portMappings": true
                },
                "type": "portmap"
            },
            {
                "type": "firewall"
            },
            {
                "type": "tuning"
            }
        ]
    }
]

Output of podman version:

Client:
Version:      3.4.0
API Version:  3.4.0
Go Version:   go1.17.1
Built:        Thu Sep 30 20:44:31 2021
OS/Arch:      darwin/amd64

Server:
Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.16.6
Built:        Mon Aug 30 22:46:36 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.22.3
  cgroupControllers: []
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.29-2.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.29, commit: '
  cpus: 1
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: localhost
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.13.16-200.fc34.x86_64
  linkmode: dynamic
  logDriver: ""
  memFree: 3644575744
  memTotal: 4104728576
  ociRuntime:
    name: crun
    package: crun-1.0-1.fc34.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.0
      commit: 139dc6971e2f1d931af520188763e984d6cdfbf8
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/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.1.12-2.fc34.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 0
  swapTotal: 0
  uptime: 20m 17.49s
plugins:
  log: null
  network: null
  volume: null
registries:
  search:
  - docker.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 11
    paused: 0
    running: 0
    stopped: 11
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 4
  runRoot: /run/user/1000/containers
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 3.3.1
  Built: 1630356396
  BuiltTime: Mon Aug 30 20:46:36 2021
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.3.1

Package info (e.g. output of rpm -q podman or apt list podman):

$ brew list podman
/usr/local/Cellar/podman/3.4.0/bin/podman
/usr/local/Cellar/podman/3.4.0/bin/podman-remote
/usr/local/Cellar/podman/3.4.0/etc/bash_completion.d/podman
/usr/local/Cellar/podman/3.4.0/libexec/gvproxy
/usr/local/Cellar/podman/3.4.0/share/fish/vendor_completions.d/podman.fish
/usr/local/Cellar/podman/3.4.0/share/man/ (160 files)
/usr/local/Cellar/podman/3.4.0/share/zsh/site-functions/_podman

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 4
  • Comments: 31 (15 by maintainers)

Most upvoted comments

A manual image path can be provided:

Taking the latest testing-devel qemu build from: https://builds.coreos.fedoraproject.org/browser?stream=testing-devel&arch=x86_64

podman machine init --image-path https://builds.coreos.fedoraproject.org/prod/streams/testing-devel/builds/34.20211011.20.0/x86_64/fedora-coreos-34.20211011.20.0-qemu.x86_64.qcow2.xz

From there I can run podman machine start, and podman machine ssh:

(base) ➜  ~ podman machine ssh
Connecting to vm podman-machine-default. To close connection, use `~.` or `exit`
Warning: Permanently added '[localhost]:63659' (ECDSA) to the list of known hosts.
Fedora CoreOS 34.20211011.20.0
Tracker: https://github.com/coreos/fedora-coreos-tracker
Discuss: https://discussion.fedoraproject.org/c/server/coreos/

[core@localhost ~]$ podman --version
podman version 3.4.0
[core@localhost ~]$ 

Additionally, I can confirm that running the testing-devel version of coreos with podman 3.4 via the temporary workaround above resolves the “unexpected end of JSON input” errors I’ve been encountering!

podman 3.4 landed in coreos next-devel a few hours ago, so it should be in the upcoming build for the next stream: https://builds.coreos.fedoraproject.org/browser?stream=next-devel&arch=x86_64

That seems like the best workaround so far, should probably be featured on the home page

If you’re on M1 podman machine init --image-path https://builds.coreos.fedoraproject.org/prod/streams/testing-devel/builds/34.20211015.20.0/aarch64/fedora-coreos-34.20211015.20.0-qemu.aarch64.qcow2.xz

Duplicate of containers/podman#11413 Should be fixed once podman 3.4 lands in CoreOS, as workaround you have to forward at least one port, e.g. -p 8080.

I am 100% in sympathy that this is a tricky problem, but I want to point out that these kinds of issues make it very hard to convince developers to use podman instead of docker. For all docker’s faults, they do the exact same thing on Mac (run a VM machine) but they never asked the user to determine which machine image to use.

If a new version of podman requires an updated machine image, then it should detect the problem and if not fix it, provide instructions to the user much better than this error message.

Please open an issue to show this.

Maybe the “image path” (i.e. CoreOS stream) should show in the machine list ? (especially since it changed from 3.3 to 3.4)

podman 3.4.0 is now available in the coreOS image. The workarounds mentioned above are no longer required.

just a +1 that I encountered the same issue “error configuring network namespace for container …” and the workaround fixed it

However, testing and next both seem to still have podman 3.3.1: https://getfedora.org/en/coreos?stream=testing

coreos

Any update on when this fix will be available for download from homebrew?