podman: All docker-compose volumes fail with: "Error response from daemon: fill out specgen: /data: duplicate mount destination"
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Any docker-compose file which declares a volume is failing.
Steps to reproduce the issue:
-
Declare a volume in docker-compose.yaml
-
Run
docker-compose up
Describe the results you received:
Error response from daemon: fill out specgen: /data: duplicate mount destination (/data depending on the volume mount locations setting).
Describe the results you expected:
Volume created and containers setup.
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Version: 3.4.0
API Version: 3.4.0
Go Version: go1.17.1
Git Commit: 6e8de00bb224f9931d7402648f0177e7357ed079
Built: Fri Oct 1 11:14:18 2021
OS/Arch: linux/amd64
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.23.1
cgroupControllers: []
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: /usr/bin/conmon is owned by conmon 1:2.0.30-1
path: /usr/bin/conmon
version: 'conmon version 2.0.30, commit: 2792c16f4436f1887a7070d9ad99d9c29742f38a'
cpus: 8
distribution:
distribution: arch
version: unknown
eventLogger: journald
hostname: mercury2
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65537
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65537
kernel: 5.14.8-arch1-1
linkmode: dynamic
logDriver: journald
memFree: 39771189248
memTotal: 41912086528
ociRuntime:
name: crun
package: /usr/bin/crun is owned by crun 1.1-1
path: /usr/bin/crun
version: |-
crun version 1.1
commit: 5b341a145c4f515f96f55e3e7760d1c79ec3cf1f
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +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: /etc/containers/seccomp.json
selinuxEnabled: false
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: /usr/bin/slirp4netns is owned by slirp4netns 1.1.12-1
version: |-
slirp4netns version 1.1.12
commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
libslirp: 4.6.1
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.2
swapFree: 0
swapTotal: 0
uptime: 16m 19.2s
plugins:
log:
- k8s-file
- none
- journald
network:
- bridge
- macvlan
volume:
- local
registries:
search:
- docker.io
store:
configFile: /home/njohnson/.config/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions: {}
graphRoot: /home/njohnson/.local/share/containers/storage
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 5
runRoot: /run/user/1000/containers
volumePath: /home/njohnson/.local/share/containers/storage/volumes
version:
APIVersion: 3.4.0
Built: 1633083258
BuiltTime: Fri Oct 1 11:14:18 2021
GitCommit: 6e8de00bb224f9931d7402648f0177e7357ed079
GoVersion: go1.17.1
OsArch: linux/amd64
Version: 3.4.0
Package info (e.g. output of rpm -q podman or apt list podman):
Name : podman
Version : 3.4.0-1
Description : Tool and library for running OCI-based containers in pods
Architecture : x86_64
URL : https://github.com/containers/podman
Licenses : Apache
Groups : None
Provides : None
Depends On : cni-plugins conmon containers-common crun fuse-overlayfs iptables libdevmapper.so=1.02-64 libgpgme.so=11-64 libseccomp.so=2-64 slirp4netns
Optional Deps : apparmor: for AppArmor support
btrfs-progs: support btrfs backend devices
catatonit: --init flag support
podman-docker: for Docker-compatible CLI [installed]
Required By : podman-docker
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 72.66 MiB
Packager : David Runge <dvzrv@archlinux.org>
Build Date : Fri 01 Oct 2021 11:14:18 AM BST
Install Date : Fri 01 Oct 2021 12:05:52 PM BST
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
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: 5
- Comments: 29 (10 by maintainers)
Commits related to this issue
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to mheon/libpod by mheon 2 years ago
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to gcalin/podman by mheon 2 years ago
- Add option for pod logs to display different colors per container. Signed-off-by: Krzysztof Baran <krysbaran@gmail.com> Signed-off-by: Calin Georgescu <caling@protonmail.com> Improve the error messag... — committed to gcalin/podman by gcalin 2 years ago
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to gcalin/podman by mheon 2 years ago
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to gcalin/podman by mheon 2 years ago
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to gcalin/podman by mheon 2 years ago
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to gcalin/podman by mheon 2 years ago
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to gcalin/podman by mheon 2 years ago
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to gcalin/podman by mheon 2 years ago
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to gcalin/podman by mheon 2 years ago
- Deduplicate between Volumes and Mounts in compat API Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, d... — committed to gbraad-redhat/podman by mheon 2 years ago
I can now confirm that BuildKit no longer seems to be a requirement for Compose v2.0, which unblocks the rest of this work. Beginning work on fixing this volume issue now. Seems like Compose is passing the
/datamount in two separate places, for unclear reasons; deduplicating it should be sufficient to fix. Hope to get a patch out tomorrow.We’re still investigating compose 2.0 compatibility - safest to stick with 1.x for now. I know that building with Compose 2.0 is also broken right now.
(On the plus side, Compose 2.0 also offers some exciting opportunities to integrate with Podman more closely, so we’re also investigating there)
Also, can you open a fresh issue on this? Entire issue template would be useful to help debug.
I’ll take a look on Monday.
No, largely because there’s a more critical problem blocking Compose v2.0 - it requires support for the Buildkit API to be present to build images, which we presently do not have. We’re going to be looking at this over the coming months to try and address it, but we don’t feel like fixing minor bugs like this makes much sense until we’ve got core features (building images) ready and working.
Looks like docker-compose was very recently (sept 28th) upgraded to version 2.0.0 for Arch: https://github.com/archlinux/svntogit-community/commits/packages/docker-compose/trunk
Downgrading back to version 1.29.2 fixes things for me.
Is version 2 of docker compose not compatible?