moby: Named volumes do not copy existing data from image path to volume.

When a container is created, a volume can be used which is mounted on a directory which already contains data from the image.

For anonymous volumes, this data is copied to the volume before mounting over the directory in the image.

However, for named volumes, this data is not copied. Even if the volume driver is local.

Here is the anonymous volume case:

$ docker run -it --rm -v /home busybox sh
DEBU[0088] Registering new volume reference: driver , name 9829aab88c7b64631f6472ecb97a18643258389d3027f90192c573f33e32c450 
DEBU[0088] Incrementing volume reference: driver local, name 9829aab88c7b64631f6472ecb97a18643258389d3027f90192c573f33e32c450 
DEBU[0088] Creating dest directory: /var/lib/docker/volumes/9829aab88c7b64631f6472ecb97a18643258389d3027f90192c573f33e32c450/_data 
DEBU[0088] Calling TarUntar(/var/lib/docker/devicemapper/mnt/5704f1232e1ef266ffba028f655d61cbbdc4aeb9726fd3f661d3f2c394d1ebe2/rootfs/home, /var/lib/docker/volumes/9829aab88c7b64631f6472ecb97a18643258389d3027f90192c573f33e32c450/_data) 
DEBU[0088] TarUntar(/var/lib/docker/devicemapper/mnt/5704f1232e1ef266ffba028f655d61cbbdc4aeb9726fd3f661d3f2c394d1ebe2/rootfs/home /var/lib/docker/volumes/9829aab88c7b64631f6472ecb97a18643258389d3027f90192c573f33e32c450/_data) 
# ls /home
default  ftp

And here is the named volume case:

$ docker run -it --rm -v myvol:/home busybox sh
DEBU[57755] Registering new volume reference: driver local, name myvol 
DEBU[57755] Incrementing volume reference: driver local, name myvol 
# ls /home
# 

So the question is: why is this behavior different? This behavior should not be different. And I’m sure this used to work in the past, perhaps in 1.8? Please take a look. Thanks!

It seems to me that daemon.createContainerPlatformSpecificSettings() is not even being called for the named volume case.

$ bundles/1.10.0-dev/dynbinary/docker version
Client:
 Version:      1.10.0-dev
 API version:  1.22
 Go version:   go1.5.2
 Git commit:   75d69ce-dirty
 Built:        Mon Dec 14 23:27:34 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.0-dev
 API version:  1.22
 Go version:   go1.5.2
 Git commit:   75d69ce-dirty
 Built:        Mon Dec 14 23:27:34 2015
 OS/Arch:      linux/amd64

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Reactions: 1
  • Comments: 18 (17 by maintainers)

Most upvoted comments

This is also discussed here: https://github.com/docker/docker/issues/17470

I’ll repeat what I said there: -v /host/path:/container/path does not copy data -v /container/path will copy data and creates new volume with a random name -v name:/container/path does not copy data but creates a new volume with the name name

Wouldn’t it be better to have a consistent implementation, so that either data is always copied, or never copied? I’m expecting several duplicates of this issue to pop up, since people might try the second case first (default, random container) and then give the volume a name and find that it behaves different.

@mariusGundersen the “bind a host path” (-v /host/path:/container/path) case was also discussed in https://github.com/docker/docker/pull/9092, I was on the fence at that time (for cases where the “host path” didn’t exist, so the directory was created automatically), but given that we’re deprecating that behavior (see https://github.com/docker/docker/pull/16349), I don’t think we should change it.

I do agree, however that -v name:/container/path should copy container data to the volume (if it’s empty!), or have an option to allow doing so. Currently, named volumes are not populated, which makes them not a viable alternative to “nameless” volumes. Just my 0.02c 😄

It’s not a bug, it acted as that because it should do that. For the anonymous volume, docker knows that the volumes is fully controlled by itself, so docker can do anythings it thinks correct(Here is copying files in image to the volume). But the named volume is designed for the volume plugin, so docker does not know what it should do, and does nothing.