-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
All docker-compose volumes fail with: "Error response from daemon: fill out specgen: /data: duplicate mount destination" #11822
Comments
Can you please share your docker-compose.yml file. |
It's reproducible on the demo docker compose files for me: https://github.com/docker/awesome-compose/blob/master/gitea-postgres/docker-compose.yaml |
This compose file works for me, can you share more details. |
This has started recently (within the last month), but was not due to the recent upgrade to 3.4.0. It was all effecting me on 3.3.1. I am running podman as a user service with systemctl:
And have the
I don't have any configuration under |
Please provide all containers.conf files - |
And for what its worth:
|
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? |
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) |
Ah, got it. I think I ran into the build issue on 2.0 as well. Is there an issue I can subscribe to in order to follow along? |
A friendly reminder that this issue had no activity for 30 days. |
A friendly reminder that this issue had no activity for 30 days. |
A friendly reminder that this issue had no activity for 30 days. |
A friendly reminder that this issue had no activity for 30 days. |
@github-actions[bot] a friendly reminder that this issue is still relevant. |
@mheon is there any development on this issue? I just tested with Podman 4.0 and compose 2.2.3 and it is still a no-go for mounting containers with Do we have any workaround at this moment? |
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. |
@mheon Thanks for the follow-up. I don't want to diverge from the original topic, but is there still an issue with building images? I remember one when Compose was just released but it seems to be fixed at this point - as far as I have tested, building images is working well at least for my use cases so far. |
@kriansa Really? Interesting - if we can confirm that Buildkit is no longer required that'd be a massive relief. @L0g4n Official answer is going to be |
@mheon Yes. Right now I'm using podman 4.0.0 and compose 2.2.3 (latest) and I can build my images just fine using The main pain point for ditching docker completely from my computer is now the volumes issue. It can be reproduced by this ---
volumes:
db_data:
services:
database:
image: docker.io/library/mariadb:10.6.5
volumes:
- db_data:/var/lib/mysql Then try to |
@kriansa exact same issue. |
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 |
Docker Compose v2.0 passes mount specifications in two different places: Volumes (just the destination) and Mounts (full info provided - source, destination, etc). This was causing Podman to refuse to create containers, as the destination was used twice. Deduplicate between Mounts and Volumes, preferring volumes, to resolve this. Fixes containers#11822 Signed-off-by: Matthew Heon <[email protected]>
Sadly 🙈 I still get this error with podman 4.1.0 and docker-compose 2.5.0 on macOS Catalina 10.15.7 with this simple docker-compose.yaml: https://github.com/nocodb/nocodb/blob/master/docker-compose/pg/docker-compose.yml Exporting DOCKER_BUILDKIT=0 in ~/.bashrc or calling docker-compose like: |
I'll take a look on Monday. |
Also, can you open a fresh issue on this? Entire issue template would be useful to help debug. |
@mheon Thanks for the quick response! I actually was setting up the fresh issue when I noticed the following: Running As far as I can can tell, podman machine just doesn't yet have a fedora-coreos image with podman 4.1 😅. P.S. About that |
Error still exists with podman 4.1.1 and docker compose version 2.7.0 this occoured if i try to install mailcow-dockerized |
Please open a fresh issue and fill out the full issue template, this should already be fixed. |
Very similar case ( Solved by upgrading to Docker Compose version v2.15.1. |
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
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):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.):
The text was updated successfully, but these errors were encountered: