Skip to content

daemon/volumes: More fs friendly image mount layer names#51827

Merged
thaJeztah merged 1 commit intomoby:masterfrom
vvoland:fix-image-mount
Jan 8, 2026
Merged

daemon/volumes: More fs friendly image mount layer names#51827
thaJeztah merged 1 commit intomoby:masterfrom
vvoland:fix-image-mount

Conversation

@vvoland
Copy link
Contributor

@vvoland vvoland commented Jan 8, 2026

daemon/volumes: More fs friendly image mount layer names

Hash the container ID, mount source and destination together to form a layer name.

This ensures the generated names are filesystem-friendly and don't exceed path length limits while maintaining uniqueness across different mount points and containers.

Fix image mounts failing with "file name too long" for long mount paths

Hash the container ID, mount source and destination together to form a
layer name.

This ensures the generated names are filesystem-friendly and don't
exceed path length limits while maintaining uniqueness across different
mount points and containers.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
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

Comment on lines +265 to +266
destHash := sha256.Sum256([]byte(ctr.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.

Ugh; saw the report indeed. ISTR we did the hex encoding to still be able to correlate the mount for debugging.

I guess we can't, unless there's some other way to add metadata to this; only thing I could consider is (if useful) to add something like "ctr-"+ctr.ID + "-src-" as prefix (assuming combination of container-ID + digest isn't too long).

Copy link
Contributor Author

@vvoland vvoland Jan 8, 2026

Choose a reason for hiding this comment

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

Yeah I think it might be too long because there's also the snapshotter dir prefix that must be accounted for (and it would be even longer for rootless).

I think we could add labels to snapshots with additional metadata that could help correlating them but it needs some plumbing.

@thaJeztah thaJeztah merged commit 7bdc756 into moby:master Jan 8, 2026
224 of 232 checks passed
@apollo13
Copy link

apollo13 commented Jan 8, 2026

Lovely, thank you for the quick turnaround!

@thaJeztah
Copy link
Member

Thanks for reporting and digging into the problem; I saw the ticket, but didn't yet get round to finding the root-cause! Once we had that, the fix was relatively easy 😄

@apollo13
Copy link

apollo13 commented Jan 8, 2026

No problem, we noticed it after an update and then did a binary search to pinpoint the release. Sadly 29.0.0 was rather large so it took a while to find in the merge requests… While we are on the topic of image mounts: Any chance I might be able to bribe you into looking at #50999 -- we can easily work around that since we don't have to use subpaths but imo it is always surprising and annoying when a docker container doesn't come up after a reboot due to bugs like that.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Docker Compose "type: image" mount fails on Linux with "file name too long" when image path contains long registry namespace

3 participants