podman rejects duplicate mount specifications

[avikivity]

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

/kind bug

Description

podman rejects duplicate mount specifications in the run command, contrary to docker

Steps to reproduce the issue:

1. $ podman run -it --rm -v $PWD:$PWD -v $PWD:$PWD fedora:30 bash

Describe the results you received:

Error: /home/avi: duplicate mount destination

Describe the results you expected:

Successful execution of the container with the mounts deduplicated

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

The duplicate mount specifications were generated by a script. I could deduplicate it, but I believe full command line compatibility is the goal.

Output of podman version:

podman version 1.6.1

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.9
  podman version: 1.6.1
host:
  BuildahVersion: 1.11.2
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.1-1.fc30.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.1, commit: 4346fbe0b2634b05857973bdf663598081240374'
  Distribution:
    distribution: fedora
    version: "30"
  MemFree: 4698271744
  MemTotal: 33600290816
  OCIRuntime:
    package: runc-1.0.0-93.dev.gitb9b6cc6.fc30.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc8+dev
      commit: e3b4c1108f7d1bf0d09ab612ea09927d9b59b4e3
      spec: 1.0.1-dev
  SwapFree: 16869486592
  SwapTotal: 16869486592
  arch: amd64
  cpus: 8
  eventlogger: journald
  hostname: tmp.scylladb.com
  kernel: 5.2.17-200.fc30.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-4.git19d199a.fc30.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.2
      commit: 19d199a6ca424fcf9516320a327cedad85cf4dfb
  uptime: 69h 19m 2.3s (Approximately 2.88 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/avi/.config/containers/storage.conf
  ContainerStore:
    number: 3
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.6.3-2.0.dev.git46c0f8e.fc30.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.6.3
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/avi/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 3
  RunRoot: /run/user/1000
  VolumePath: /home/avi/.local/share/containers/storage/volumes

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

podman-1.6.1-2.fc30.x86_64

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

None

[rhatdan]

I don't believe we strive to be bug for bug compatible with Docker. To me this is a bug and should be reported to the user. Docker should also report an error.

[mheon]

Docker does allow for duplicate mount destinations, but only so long as the mounts are completely identical. I think this might be reasonable to do - reopening.

[rhatdan]

Why? What would be the reasoning for allowing to volumes to be exactly the same, other then a bug?

[mheon]

Sorry for the delay, #4462 to fix

[rhatdan]

I reject this as a bug. We don't have to be bug for bug compatible with Docker. Ignoring this might leave a caller confused because of a typo. It is better to report the error.

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[mheon]

With 4462 closed, I think we'll just close this as NOTABUG.

[beatboxchad]

Why? What would be the reasoning for allowing to volumes to be exactly the same, other then a bug?

To accommodate machine-generated YAML or API calls, such as with docker-compose.

Thus, this issue is breaking the new, exciting docker-compose compatibility. I ran into the same problem described in a comment on issue 11717.

This constrains shops/teams who want to adopt Podman but keep the developer experience consistent. Many developers use Compose for their dev environments, and it's a nice way to include Windows/Mac devs who don't want to run a Linux VM to use Podman.

One could argue that docker-compose devs ought to de-duplicate the YAML or the API calls (however it's implemented), for cleaner engineering. I find this reasoning sound, and in keeping with what you've stated.

But in practice, I wonder if it's more valuable to make a concession and, as long as keys are truly identical, ignore it. This course of action looks like the least work for tooling interoperability, since there is already a pull request

[rhatdan]

Could you open a new issue. I think with the compat layer, we should fix this. I am not sure if we want to fix it as deply as we did in the first PR.

[mheon]

Concur with this being a separate issue. We have no intention of fixing this for the Podman CLI. For the Docker-compat remote API, which did not exist when this issue was originally created, we have a stronger compatibility guarantee, so we'll have to fix it there.

I will note that this is not the only thing preventing Compose v2.0 from working (there were a rash of changes to how images were built, which are substantially trickier; we're going to look into them, but I doubt we'll have time before the new year at earliest, most of the team is busy on the network rewrite to get Podman v4.0 out the door). We strongly recommend downgrading to Compose v1.x, which does work, until we can get Compose v2.0 working.

[kriansa]

FYI: the compose compatibility issue is being tracked here #11822

[DevDorrejo]

Hello this issue happen on last upstream too, /tmp: duplicate mount destination

[mheon]

Yes, and we have no intention of fixing it in the CLI as, in our eyes, it's a bug in Docker. For the Docker-compatible API, we will fix it, as we guarantee bug-for-bug compat there; this has not been done yet.

[DevDorrejo]

Yes, and we have no intention of fixing it in the CLI as, in our eyes, it's a bug in Docker. For the Docker-compatible API, we will fix it, as we guarantee bug-for-bug compat there; this has not been done yet.

Thank you very much for the reply, i will go to bother docker to fix this issue XD.

[rcannood]

Big fan of podman here. However, this has got to be one of the weirdest bug reports I've seen thus far.

It's not a feature, it's a bug.

😐

[rhatdan]

@rcannood you think we should not report a problem with the same mount specified in the command line multiple times?

[rcannood]

Thanks for asking me to elablorate!

If podman was something that was developed completely separately from docker, I think the current approach 100% makes sense. But that is not the case, and many people (including me) first started using podman as a drop in replacement for docker.

I don't think this is an issue for direct users of podman as they can simply edit their command. The issue mostly arises when dealing with other tooling software (such as docker compose, such as nextflow, such as viash) which attempt to auto detect mount paths from a set of input files. If those input files originate from the same directory, they might mount the same directory multiple times (with exactly the same source and destination paths).

Users of those tools cannot use podman instead of docker, or have to file bug reports to the maintainers of those tools to get them to solve the issue.

In my opinion, it would be great if podman could produce an error when there are conflicting mount paths (i.e. multiple source paths to the same dest path) but only generate a warning when the same src:dest specification is provided multiple times. That way, existing scripts and tools still work with podman even when they forget to remove duplicate mount paths.

[rhatdan]

That seems reasonable to me. Care to open a PR for this?

[rcannood]

Aha! I was wondering whether you meant that I should open a PR.

I was about to look into this, but I see that you already made the necessary changes and that it was even already merged into the main branch.

Thanks a ton @rhatdan for being so open-minded on this :)

[rhatdan]

Yes I had some spare cycles to work on it, so I figured I would knock it out. Thanks for reporting.