File volumes are broken for docker 1.4.0

[saks]

Fig will mount empty directory instead of file with docker > 1.3.3

$ cd /tmp
$ fig --version
# fig 1.0.0
$ docker --version
# Docker version 1.4.0, build 4595d4f
$ touch /tmp/test_file
$ cat > /tmp/fig.yml
# paste config
$ fig run --rm test
# cat: /tmp/test_file: Is a directory
# Removing tmp_test_run_1...

test:
  command: cat /tmp/test_file
  image: debian:wheezy
  volumes:
    - "/tmp/test_file:/tmp/test_file"

[ghost]

Experiencing the same.

[zulkamal]

Same here

[morvans]

Same here, too

[tomfotherby]

Yep, This issue breaks lots of things in our project. I have had to stop using fig after I upgraded to v1.4 and instead use raw docker run commands.

[morvans]

Not a change I'm able to stop using fig easily, it's part of the developer team stack here. We downgraded to docker 1.3.3

[LordFPL]

Hello,

Same problem here... and find why with inspect command... fig is filling config/volumes with for example :
"Volumes": {
"/data": {},
"/opt/socket": {},
"/plugins": {}
},
(normal behaviour is to see "Volumes": null,)

On the Binds part... he is adding :rw... no the cause of the problem here, but it's not what i'm asking in my fig.yml (external_mount:container_mount:rw, but my file is external_mount:container_mount)

On the last part... Volumes part... we have a full local mounts :
"Volumes": {
"/data": "/var/lib/docker/vfs/dir/7054d3742ec13b6d5cb9865c672dae7878852f0aef4c40afac2d6dd8628a8434",
"/opt/socket": "/var/lib/docker/vfs/dir/a773d8fd2fb382ca7068b7d1463614ab276994a20b9efcfa52642f9fc8be460b",
"/plugins": "/var/lib/docker/vfs/dir/fe90471a4a9c67665bdff8800300211b62d263400b5ff25cc2cb40aa4d1e5f87"
},

I'm moving to crane (https://github.com/michaelsauter/crane) and wait for a full integration in docker (compose).

[coaxial]

Yep, same here. Downgrading to 1.3.3 fixes it.

[dnephin]

See moby/moby#9628

I would guess it will be fixed in docker 1.4.1. I think we can fix it in fig as well.

[slava-vishnyakov]

👍 also experiencing it. Hoping for a fix.. Downgrading to 1.3.3 helps

[bfirsh]

Fix is in moby/moby#9631

[crosbymichael]

Yes, this is a docker bug and will be fixed ASAP. Sorry. This got "deprecated" but was not the case as deprecating this part breaks critical aspects of docker as you can see for third party clients.

Won't happen again.

[crosbymichael]

FYI, I don't think you all need to fix this in fig, it's not deprecated and will not be.

[crosbymichael]

We merged the fix and you can test with binaries found on:
https://master.dockerproject.com/

We are also staging a release for this fix here:
moby/moby#9679

[chmouel]

I had the exact same problem and compiled in with this fix which worked for me

[jcalazan]

v1.4.1 is out now, confirmed it fixed this issue on my machine

[crosbymichael]

Thanks for confirming and yes, docker 1.4.1 is out with the fix

[dreamcat4]

Then I don't understand why mine isn't working if 1.4.1 is supposed to have fixed the issue. I have upgraded from docker v1.10 --> 1.4.1 (build 5bc2ff8). with fig 1.0.1 on ubuntu 14.10. And the volumes don't mount for me.

I upgraded my docker to 1.4.1 from this apt repo: deb-src: https://get.docker.io/ubuntu docker main. Before that it was installed the older version in default official ubuntu repos.

[morvans]

Do you "fig rm" you containers before "fig up"ing them again ?

[dreamcat4]

@morvans No. I was not aware being such a new user. Thank you so much! After doing fig rm --force; fig build; fig up. Now it has worked correctly and mounted the host volumes inside the container.

volumes_from: also works too now. I am very grateful for this.

[morvans]

You wouldn't actually have to fig rm your existing containers if we could manage to eradicate #622...

[Vrakfall]

Thanks a lot @morvans. I was experiencing the same problem than @dreamcat4 and you made me win a lot of time figuring what the hell was happening. ^^