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:

  1. Declare a volume in docker-compose.yaml

  2. 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

Most upvoted comments

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 /data mount 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.

pacman -U /var/cache/pacman/pkg/docker-compose-1.29.2-1-any.pkg.tar.zst

Is version 2 of docker compose not compatible?