mount API is not strictly equivalent to bind

[ndeloof]

What I did
A volume mount with an actual bind (driver option o: bind) must be configured using bind API otherwise we get some weird behavior

Related issue
https://docker.atlassian.net/browse/CSESC-577

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[thaJeztah]

@ndeloof I think this was the comment where the original idea of “allow a named volume with a custom host path” (so, largely a “bind-mount”) comes from; moby/moby#19990 (comment)

Note that the comment was really a "hack"; it depends on knowing the right options for the mount syscall, and it's tricking the docker engine into thinking it deals with a volume, not a bind-mount (to do the "copy files to the target destination").

One thing to be aware of is that in that (technically) “o=bind” could have multiple options; also (as mentioned) that it DOES act as a volume, because the docker engine is not aware of the mount syscall options; for example;

docker volume create --opt type=none --opt device=/root/mount-target --opt o=bind bindvolume

This is expected: docker is not aware of any host-path dependency that the mount syscall options require;

docker run --rm -v bindvolume:/usr/share/nginx/ nginx:alpine sh -c 'echo hello > /usr/share/nginx/html/foo.txt'
# docker: Error response from daemon: failed to mount local volume: mount /root/mount-target:/var/lib/docker/volumes/bindvolume/_data, flags: 0x1000: no such file or directory.

Creating the path first makes it work, but also be aware that the Docker Engine considers it a volume, so (unlike a bind-mount) will copy files to the given location if the target path on the host is empty;

mkdir -p /root/mount-target
docker run --rm -v bindvolume:/usr/share/nginx/ nginx:alpine sh -c 'echo hello > /usr/share/nginx/html/foo.txt'

tree /root/mount-target
/root/mount-target
└── html
    ├── 50x.html
    ├── foo.txt
    └── index.html

1 directory, 3 files

[apollo13]

Hi, just stumbled over this by accident. We are using volumes like @thaJeztah showed to have docker volumes with the copy behavior on a custom host path. Another upside is that deleting the volume does not delete the underyling data :)

I don't fully understand what this MR changes, but it would be great if this "hack" would continue to work (or at least offers a different way to achieve the same).

[thaJeztah]

Another upside is that deleting the volume does not delete the underyling data :)

In general, named volumes were designed for that specifically; if a volume has a name, docker will avoid deleting it (unless you ask it to), e.g. docker volume prune won't remove named volumes by default. The downside of using this hack (at least on Docker Desktop) is that the files are copied out of the VM onto the host, and mounted back. This means that any file operation will have the overhead of bridging the host <--> VM boundary, which can be significant for containers doing many file operations on those files (in addition to overhead for trying to preserve file-metadata (permissions, other attributes), which is not always possible cross-platform (linux <--> macOS, or linux <--> Windows).

[apollo13]

In general, named volumes were designed for that specifically; if a volume has a name, docker will avoid deleting it (unless you ask it to), e.g. docker volume prune won't remove named volumes by default.

Yes, but adding a label to a volume is not something docker compose can do without destroying the volume which is unfortunate.

The downside of using this hack (at least on Docker Desktop) is that the files are copied out of the VM onto the host, and mounted back.

Yes, but using a VM can already be considered a hack in itself :D

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[glours]

Sounds good to me, we just need to double check the TypeNamedPipe case