-
Notifications
You must be signed in to change notification settings - Fork 18.6k
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
Volume driver plugin receives Mount
requests with identical ID
s when doing docker container cp
on a running container
#47964
Comments
I see you're running a build from master (4fec999); is this a regression, and did this work correctly with previously released versions? |
No, that's a side effect of my debugging attempt. Just checked with the released version: docker version
docker info
|
Current stateI was trying to analyze the issue. Here is the call stack from the Full call stack
So, (for context: the only other function in the code base besides HistoryI tried going back with |
Judging by the commit message of 2bdc7fb, it is not a bug that volumes are mounted again, even when a container is already running. Based on the following comments from volume/mounts/mounts.go: Lines 62 to 64 in 11179de
mounts.MountPoint.active :Lines 75 to 78 in 11179de
, it seems like the authors intended that mounts of a container are reused in operations like docker cp . However, this results in the behavior I described above, which contradicts the documentation.
So! In my understanding, there should not even exist a structure that combines the active mounts counter and a mount ID. It seems that there are two different entities (both currently represented with @thaJeztah, what do you think? Does it make sense? |
Context: there used to be the pair of `MountPoint.ID` and `MountPoint.active` to track mounts of a mountpoint (which there is usually just one but may be more, e.g., when doing `docker cp`). This is not conceptually right, as an ID shall correspond to a mount, rather than a mountpoint, which led to incorrect behavior (e.g., moby#47964). Here IDs are reworked such that every mountpoint tracks the list of mounts, each with its own id, with (up to) one mount being considered the primary mount (the one used for container operation, rather than `docker cp`). One side effect of the patch is that now all mounts, including the bind ones, are assigned an ID, for the sake of consistency. Other files/modules relying on mountpoint ids are updated accordingly. On linux, the moby#47964 behavior now works correctly. Windows volume/mountpoint logic was not fixed yet. Signed-off-by: Nikolay Nechaev <[email protected]>
Context: there used to be the pair of `MountPoint.ID` and `MountPoint.active` to track mounts of a mountpoint (which there is usually just one but may be more, e.g., when doing `docker cp`). This is not conceptually right, as an ID shall correspond to a mount, rather than a mountpoint, which led to incorrect behavior (e.g., moby#47964). Here IDs are reworked such that every mountpoint tracks the list of mounts, each with its own id, with (up to) one mount being considered the primary mount (the one used for container operation, rather than `docker cp`). One side effect of the patch is that now all mounts, including the bind ones, are assigned an ID, for the sake of consistency. Other files/modules relying on mountpoint ids are updated accordingly. On linux, the moby#47964 behavior now works correctly. Windows volume/mountpoint logic was not fixed yet. Signed-off-by: Nikolay Nechaev <[email protected]>
Description
When a container is running and a volume is mounted with a volume driver plugin, running
docker container cp
results in the plugin receivingMount
requests with duplicate IDs (as well as the correspondingUnmount
requests)Reproduce
Compile and run with sufficient permissions the following dummy driver
dummy_driver.go
docker run --rm -d -v foo:/foo --name my-alpine alpine:latest sleep 120
docker cp my-alpine:/bin/sh /tmp/
Expected behavior
The plugin should have received either one pair of Mount-Unmount requests or two pairs (as in Mount - Mount-Unmount - Unmount) requests with two distinct IDs.
docker version
Client: Version: 26.1.4 API version: 1.45 Go version: go1.22.3 Git commit: 5650f9b102 Built: Thu Jun 6 18:42:55 2024 OS/Arch: linux/amd64 Context: default Server: Engine: Version: dev API version: 1.46 (minimum version 1.24) Go version: go1.22.4 Git commit: 4fec999c1182face1fd9d2c25a5d6c0167603a77-unsupported Built: Wed Jun 12 15:26:40 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.7.18 GitCommit: ae71819c4f5e67bb4d5ae76a6b735f29cc25774e.m runc: Version: 1.1.12 GitCommit: docker-init: Version: 0.19.0 GitCommit: de40ad0
docker info
Additional Info
No response
The text was updated successfully, but these errors were encountered: