Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected error with --volumes-from #19529

Closed
ricardobranco777 opened this issue Aug 6, 2023 · 1 comment · Fixed by #19530
Closed

Unexpected error with --volumes-from #19529

ricardobranco777 opened this issue Aug 6, 2023 · 1 comment · Fixed by #19530
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@ricardobranco777
Copy link

Issue Description

I can't use --volumes-from.

Steps to reproduce the issue

  1. mkdir /tmp/registry
  2. podman run -d --name registry -v /tmp/registry:/var/lib/registry registry:2
  3. podman run --rm --volumes-from registry --entrypoint /bin/registry registry:2 --version

Describe the results you received

Error: baseMounts conflict at mount destination /var/lib/registry: duplicate mount destination

Describe the results you expected

I expect the latest command to work and return /bin/registry github.com/docker/distribution 2.8.2 like docker does.

podman info output

host:
  arch: amd64
  buildahVersion: 1.31.0
  cgroupControllers:
  - cpu
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.7-2.1.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: unknown'
  cpuUtilization:
    idlePercent: 97.22
    systemPercent: 0.98
    userPercent: 1.79
  cpus: 4
  databaseBackend: boltdb
  distribution:
    distribution: '"opensuse-tumbleweed"'
    version: "20230801"
  eventLogger: file
  freeLocks: 2047
  hostname: rbranco-jeos
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 100
      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: 6.4.6-1-default
  linkmode: dynamic
  logDriver: journald
  memFree: 235397120
  memTotal: 8317804544
  networkBackend: cni
  networkBackendInfo:
    backend: cni
    dns: {}
    package: |-
      cni-1.1.2-2.4.x86_64
      cni-plugins-1.1.1-2.4.x86_64
    path: /usr/libexec/cni
  ociRuntime:
    name: runc
    package: runc-1.1.8-1.1.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.1.8
      commit: v1.1.8-0-g82f18fe0e44a
      spec: 1.0.2-dev
      go: go1.20.5
      libseccomp: 2.5.4
  os: linux
  pasta:
    executable: ""
    package: ""
    version: ""
  remoteSocket:
    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: slirp4netns-1.2.0-1.3.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: unknown
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.5.4
  swapFree: 0
  swapTotal: 0
  uptime: 92h 32m 26.00s (Approximately 3.83 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.opensuse.org
  - registry.suse.com
  - docker.io
store:
  configFile: /home/opensuse/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/opensuse/.local/share/containers/storage
  graphRootAllocated: 85858074624
  graphRootUsed: 28449988608
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/opensuse/.local/share/containers/storage/volumes
version:
  APIVersion: 4.6.0
  Built: 1689897600
  BuiltTime: Fri Jul 21 00:00:00 2023
  GitCommit: ""
  GoVersion: go1.20.5
  Os: linux
  OsArch: linux/amd64
  Version: 4.6.0

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

QEMU VM & bare-metal.

Additional information

The registry:2 image has a VOLUME entry.

@ricardobranco777 ricardobranco777 added the kind/bug Categorizes issue or PR as related to a bug. label Aug 6, 2023
mheon added a commit to mheon/libpod that referenced this issue Aug 7, 2023
We do not allow volumes and mounts to be placed at the same
location in the container, with create-time checks to ensure this
does not happen. User-added conflicts cannot be resolved (if the
user adds two separate mounts to, say, /myapp, we can't resolve
that contradiction and error), but for many other volume sources,
we can solve the contradiction ourselves via a priority
hierarchy. Image volumes come first, and are overridden by the
`--volumes-from` flag, which are overridden by user-added mounts,
etc, etc. The problem here is that we were not properly handling
volumes-from overriding image volumes. An inherited volume from
--volumes-from would supercede an image volume, but an inherited
mount would not. Solution is fortunately simple - just clear out
the map entry for the other type when adding volumes-from
volumes.

Makes me wish for Rust sum types - conflict resolution would be a
lot simpler if we could use a sum type for volumes and bind
mounts and thus have a single map instead of two maps, one for
each type.

Fixes containers#19529

Signed-off-by: Matthew Heon <[email protected]>
@ricardobranco777
Copy link
Author

Thanks @mheon !

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Nov 7, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant