Skip to content

daemon: Fix mounting same image multiple times with different destinations#50268

Merged
vvoland merged 1 commit intomoby:masterfrom
vvoland:image-mount-multiple
Jul 16, 2025
Merged

daemon: Fix mounting same image multiple times with different destinations#50268
vvoland merged 1 commit intomoby:masterfrom
vvoland:image-mount-multiple

Conversation

@vvoland
Copy link
Contributor

@vvoland vvoland commented Jun 26, 2025

The previous implementation generated layer names based on container ID and source image, which would cause conflicts when mounting the same image to multiple destinations within a container.

This fixes the issue by changing the layer naming strategy to include the destination path in the layer name, making it unique for each mount point.

To avoid filesystem paths producing unexpected names, the combined string is hex-encoded and used as a layer name.

- How to verify it
TestRunMountImageMultipleTimes

- Human readable description for the release notes

Fix `--mount type=image` failure when mounting the same image multiple times to a different destinations.

- A picture of a cute animal (not mandatory but encouraged)

@vvoland vvoland added this to the 29.0.0 milestone Jun 26, 2025
@vvoland vvoland self-assigned this Jun 26, 2025
@vvoland vvoland added area/volumes Volumes area/images Image Distribution kind/bugfix PR's that fix bugs impact/changelog labels Jun 26, 2025
// This makes sure that the same image can be mounted multiple times with different destinations.
// Hash the destination to create a safe, unique identifier
destHash := sha256.Sum256([]byte(container.ID + "src=" + mp.Source + "dst=" + mp.Destination))
layerName := hex.EncodeToString(destHash[:])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would we need to correlate the ID with these anywhere? Considering if (e.g.) base64 encoding or something like that would work instead of a cryptographic hash.

What are the constraints on these names? (is this path on disk, or otherwise?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't really need to correlate these, we just need "a" name for the snapshot. I think it could only be problematic when trying to match the name when filtering snapshots?

Also not sure if there's a length limit on snapshot ids.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to hex-encoding, so it's reversible in case it's needed.

@thompson-shaun thompson-shaun added the release-blocker PRs we want to block a release on label Jul 10, 2025
@dmcgowan dmcgowan self-assigned this Jul 10, 2025
@vvoland vvoland force-pushed the image-mount-multiple branch from 5ffc521 to 07885d8 Compare July 14, 2025 16:14
…tions

The previous implementation generated layer names based on container ID
and source image, which would cause conflicts when mounting the same
image to multiple destinations within a container.

This fixes the issue by changing the layer naming strategy to include
the destination path in the layer name, making it unique for each mount
point.

To avoid filesystem paths producing unexpected names, the combined
string is hex-encoded and used as a layer name.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
@vvoland vvoland force-pushed the image-mount-multiple branch from 07885d8 to 14d9be4 Compare July 14, 2025 18:34
Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah thaJeztah requested a review from dmcgowan July 14, 2025 19:06
@vvoland vvoland merged commit e32e1f6 into moby:master Jul 16, 2025
210 of 216 checks passed
@apollo13
Copy link

apollo13 commented Jan 8, 2026

This fix seems to break image mounts completely depending on the filesystem (?) #51687

@vvoland
Copy link
Contributor Author

vvoland commented Jan 8, 2026

You're absolutely right! /s

I restored hashing the mount paths to avoid that and opened a PR: #51827

Thanks for a ping!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/images Image Distribution area/volumes Volumes impact/changelog kind/bugfix PR's that fix bugs release-blocker PRs we want to block a release on

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Mounting an image volume multiple times doesn't work

5 participants