Conflict at mount destination with podman 1.3.1 #3174
Comments
openshift-ci-robot
added
the
kind/bug
|
Also seeing the same behavior on the same version - this was a clean Fedora 30 server minimal install. Also on 1.3.1-1-git7210727.fc30.x86_64. Specifying a volume using -v always results in this error. |
|
This was my code, I'll take a look. |
|
Image volumes - has to be image volumes. We have a named volume from an image volume at Working up a patch. |
|
@mheon this is exactly what's going on - thank you so much for taking a look, and allowing me to have choice in my container life. 👍 |
When we supercede low-priority mounts and volumes (image volumes, and volumes sourced from --volumes-from) with higher-priority ones (the --volume and --mount flags), we always replaced lower-priority mounts of the same type (e.g. a user mount to /tmp/test1 would supercede a volumes-from mount to the same destination). However, we did not supercede the opposite type - a named volume from image volumes at /tmp/test1 would be allowed to remain and create a conflict, preventing container creation. Solve this by destroying opposite types before merging (we can't do it in the same loop, as then named volumes, which go second, might trample changes made by mounts). Fixes containers#3174 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
#3177 should fix |
|
Is there a work around for this while we wait for the patch to land? |
|
Try |
|
that worked! thanks! |
|
Thanks for that quick fix. |
|
@mheon Do we need a new release for this? Is this worth blocking podman 1.3.1? |
|
+1 on the new release from me, blocking I'm on the fence for. |
|
We just merged a few big PRs from Giuseppe on user namespace, so I think
our best bet is to try and cut a 1.4 next week with whatever is ready and
get that it quickly.
…On Wed, May 22, 2019, 08:50 Tom Sweeney ***@***.***> wrote:
+1 on the new release from me, blocking I'm on the fence for.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3174>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB3AOCGPTT3YF5DSPMZPEALPWU6PVANCNFSM4HOKQLNQ>
.
|
When we supercede low-priority mounts and volumes (image volumes, and volumes sourced from --volumes-from) with higher-priority ones (the --volume and --mount flags), we always replaced lower-priority mounts of the same type (e.g. a user mount to /tmp/test1 would supercede a volumes-from mount to the same destination). However, we did not supercede the opposite type - a named volume from image volumes at /tmp/test1 would be allowed to remain and create a conflict, preventing container creation. Solve this by destroying opposite types before merging (we can't do it in the same loop, as then named volumes, which go second, might trample changes made by mounts). Fixes #3174 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Podman 1.3 error with docker postgres:10-alpine image
Upgrade to f30 lead to postgresql container error
_ Work fine on v1.2
Steps to reproduce the issue:
Describe the results you received:
Error: conflict at mount destination /var/lib/postgresql/data: duplicate mount destinationpodman version:podman-1.3.1-1.git7210727.fc30
The text was updated successfully, but these errors were encountered: