Add docs for image mounts (--mount type=image)#25486
Conversation
✅ Deploy Preview for docsdocker ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟢 APPROVE
The PR adds a well-structured new page for --mount type=image, following the same template as the existing volumes/bind-mounts/tmpfs pages. No critical issues found.
What looks good:
- No vendored files touched; no redirects needed (new page, not a rename)
- Front matter includes required
title,description,keywordsfields - No AI hedge words or marketing language detected
- Markdown formatting, Hugo shortcodes, and internal links are correct
- Commands and examples are consistent with the established patterns in sibling pages
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟡 NEEDS ATTENTION
Document the image mount storage type: a new content/manuals/engine/storage/image-mounts.md page following the volumes/bind/tmpfs template, plus overview and cross-link updates in the storage section. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟡 NEEDS ATTENTION
| `type=image`. | ||
|
|
||
| ```console | ||
| $ docker run --mount type=image,src=<image-reference>,dst=<container-path> |
There was a problem hiding this comment.
[HIGH] docker run syntax examples are missing the required container image argument
Both syntax examples omit the container image positional argument that docker run requires:
$ docker run --mount type=image,src=<image-reference>,dst=<container-path>Without an image name at the end, this command will fail. Since these are presented as runnable console examples (with a $ prompt), users will copy-paste and get an error. A corrected form would be:
$ docker run --mount type=image,src=<image-reference>,dst=<container-path> <container-image>The same fix applies to the extended form on line 96.
There was a problem hiding this comment.
That example is ambiguous though so maybe using something like:
$ docker run --mount type=image,src=<mounted-image>,dst=<container-path> <runtime-image>
There was a problem hiding this comment.
Great suggestion! Using <mounted-image> and <runtime-image> makes the distinction much clearer. The current <image-reference> and <container-path> labeling doesn't help users understand that there are two images involved: the one being mounted as a data source, and the one that's actually running as the container.
Your proposal removes that ambiguity nicely — it's immediately obvious which image is which.
|
|
||
| ```console | ||
| $ docker inspect imgtest --format '{{ json .Mounts }}' | ||
| [{"Type":"image","Name":"busybox:musl","Source":"/var/lib/docker/rootfs/overlayfs/...","Destination":"/dbg","Mode":"","RW":false,"Propagation":"rprivate"}] |
There was a problem hiding this comment.
[LOW] docker inspect example path prefix may not match containerd image store output
The example output shows:
"Source":"/var/lib/docker/rootfs/overlayfs/..."
Image mounts require the containerd image store. The actual source path on a containerd-backed daemon may differ from the /var/lib/docker/rootfs/overlayfs/ prefix shown. Users comparing this to their own docker inspect output could be confused if their path looks different.
Since the value is truncated with ..., it's clearly illustrative — but confirming the path prefix against a live containerd-image-store daemon (as mentioned in the PR description) and using the real prefix would make this more accurate.
Summary
Adds documentation for the image mount storage type (
--mount type=image),which had no dedicated page. New
content/manuals/engine/storage/image-mounts.mdfollows the same template and depth as the volumes/bind/tmpfs pages, and the
storage overview plus sibling "Next steps" lists are updated to link it.
Written in anticipation of image mounts being unflagged as experimental
(moby/moby#52998), so no experimental callouts are included. Every command and
output on the page was verified against a live Docker Engine 29.6.1 daemon
(containerd image store).
Learnings
readonly=falsehas no effect;docker inspectalways reports"RW":false), the source image is notauto-pulled, there is no
-vshorthand, and executables from the mountedimage only run if the container's libc/dynamic linker matches (a glibc binary
fails in musl-based Alpine). These are easy to get wrong from the CLI help
alone — worth verifying against a daemon.
Generated by Claude Code