podman: Podman run fails to run when using named volume
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Podman runtime error when attempting to run container with named volume. Does not seem to matter if podman run is creating the volume or podman volume create. Does not matter whether container is a custom build or remote image.
Steps to reproduce the issue:
-
Run any image, specifying a named volume, e.g.
podman run -it --rm -v test:/test hello-world -
Get error output
-
Be sad.
Describe the results you received:
root@rocinante:~ # podman run -it --rm -v test:/test hello-world
Trying to pull docker.io/library/hello-world...
Getting image source signatures
Copying blob 1b930d010525 done
Copying config fce289e99e done
Writing manifest to image destination
Storing signatures
Error: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/containers/storage/btrfs-containers/a261adb857d24bc7326cec1fa0d67c74465e86b1b0ecb1d59a6d2a0e2c74f9f4/userdata/volumes/test/_data\\\" to rootfs \\\"/var/lib/containers/storage/btrfs/subvolumes/36a8a9d4e1c523dba11a9a89f599d06b8689ac1ab0508f48edd8e0f205251b3a\\\" at \\\"/test\\\" caused \\\"stat /var/lib/containers/storage/btrfs-containers/a261adb857d24bc7326cec1fa0d67c74465e86b1b0ecb1d59a6d2a0e2c74f9f4/userdata/volumes/test/_data: no such file or directory\\\"\"": OCI runtime error
Describe the results you expected: Container to mount with persistent named volume attached at specified mount point, world domination ensues shortly thereafter…
Additional information you deem important (e.g. issue happens only occasionally): Consistent behavior every time on this machine.
Output of podman version:
podman version 1.5.0
Output of podman info --debug:
root@rocinante:~ # podman info --debug
debug:
compiler: gc
git commit: ""
go version: go1.12.9
podman version: 1.5.0
host:
BuildahVersion: 1.10.1
Conmon:
package: conmon-2.0.0-2.1.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.0, commit: unknown'
Distribution:
distribution: '"opensuse-tumbleweed"'
version: "20190829"
MemFree: 3336896512
MemTotal: 8254947328
OCIRuntime:
package: runc-1.0.0~rc8-1.4.x86_64
path: /usr/sbin/runc
version: |-
runc version 1.0.0-rc8
spec: 1.0.1-dev
SwapFree: 2147483648
SwapTotal: 2147483648
arch: amd64
cpus: 4
eventlogger: file
hostname: rocinante
kernel: 5.2.10-1-default
os: linux
rootless: false
uptime: 1h 10m 11.21s (Approximately 0.04 days)
registries:
blocked: null
insecure: null
search:
- docker.io
store:
ConfigFile: /etc/containers/storage.conf
ContainerStore:
number: 1
GraphDriverName: btrfs
GraphOptions: null
GraphRoot: /var/lib/containers/storage
GraphStatus:
Build Version: 'Btrfs v5.2.1 '
Library Version: "102"
ImageStore:
number: 21
RunRoot: /var/run/containers/storage
VolumePath: volumes
Package info (e.g. output of rpm -q podman or apt list podman):
root@rocinante:~ # rpm -q podman
podman-1.5.0-1.1.x86_64
Additional environment details (AWS, VirtualBox, physical, etc.): Lenovo Thinkpad Flex 15, bare metal install
Thanks in advance!
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 17 (10 by maintainers)
Commits related to this issue
- Ensure good defaults on blank c/storage configuration If c/storage paths are explicitly set to "" (the empty string) it will use compiled-in defaults. However, it won't tell us this via `storage.GetD... — committed to mheon/libpod by mheon 5 years ago
- Ensure good defaults on blank c/storage configuration If c/storage paths are explicitly set to "" (the empty string) it will use compiled-in defaults. However, it won't tell us this via `storage.GetD... — committed to mheon/libpod by mheon 5 years ago
Appears that the volume path was indeed the issue. Re-installed from distro packages with all configuration files removed, and after re-creating policy.json with defaults and registries.conf from defaults this is working.
I’m closing this issue as it appears to be resolved to me. If you’re troubleshooting and find this issue, ensure that the
storage.DefaultStoreOptions()in/etc/containers/storage.confis correct.