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)
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.xzFrom there I can run
podman machine start, andpodman machine ssh: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.xzDuplicate 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,
testingandnextboth seem to still have podman 3.3.1: https://getfedora.org/en/coreos?stream=testingAny update on when this fix will be available for download from homebrew?