`devcontainer up --mount` rejects `type=image` and mount options such as `subpath`

Đang mở
  • Có gì không ổn?
#1,352 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@agmitron đang làm issue này rồi.

Từ ngày 6/11/2026.

  • #1353 của @agmitron — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
docker, docker-compose, typescript
Lĩnh vực
cli, devtools

Hướng nghiên cứu

Trace how the --mount flag is validated and converted, then compare it with how string mounts from devcontainer.json reach the runtime. Check the Docker Compose path, where mounts use short syntax, and define a clear rejection for unsupported mount forms there. Done means runtime string mounts are passed through for supported runtimes, existing bind/volume behavior remains covered, and the linked pull request is reviewed for overlap.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

What I want to do

I keep my personal tools (neovim, Claude Code) in a Nix-built OCI image and mount its /nix read-only into a team's dev container with an image mount. The team's devcontainer.json stays untouched, so the mount has to come from the command line:

devcontainer up --docker-path podman --workspace-folder . \
  --mount "type=image,source=localhost/devtools:latest,target=/nix,subpath=/nix"

Podman (since 5.1) and Docker Engine (since 28, with the containerd image store) support --mount type=image. Docker spells the option image-subpath instead of subpath.

What happens

The CLI exits with:

Unmatched argument format: mount must match type=<bind|volume>,source=<source>,target=<target>[,external=<true|false>]

The same string works as an entry in mounts in devcontainer.json. The CLI passes string mounts to podman run verbatim, and with --log-level trace I see:

podman run ... --mount type=image,source=localhost/devtools:latest,target=/nix,subpath=/nix ...

Inside the container, /nix is a read-only overlay, and nvim --version and claude --version run from it. So the runtime handles the mount fine; only the --mount flag refuses it.

Why

In 0.89.0 the flag goes through two steps:

  1. A fixed regex validates it: /^type=(bind|volume),source=([^,]+),target=([^,]+)(?:,external=(true|false))?$/. Any other type or option fails, including readonly.
  2. The value is parsed into a mount object, and the object is serialized back as type=...,src=...,dst=.... Options outside these three fields would be lost even if the regex allowed them.

The object form follows the spec's Mount schema (type is bind or volume, additionalProperties: false).

Proposal

When the --mount value does not match the bind/volume form, pass it to the container runtime as a string, the same way string entries in devcontainer.json mounts are handled today. The bind/volume parsing and external= keep working as now.

That covers type=image, subpath / image-subpath, readonly, volume-subpath, tmpfs and future runtime options without the CLI having to know each one. The runtime reports an invalid string itself.

For Docker Compose configs the string cannot be passed through as-is, since mounts are converted to the short source:target syntax there. Rejecting a non-bind/volume --mount with a clear error on the Compose path would be enough.

Workaround

--override-config with a full copy of the team's devcontainer.json plus the string mount. The copy has to be regenerated whenever the team changes their file, because --override-config replaces the config instead of merging it.

Environment
  • @devcontainers/cli 0.89.0
  • Podman 6.1.4, rootless, Debian 13 (Linux 6.12, x86_64)
Related
  • devcontainers/spec#781: the Feature Mount schema rejects --mount options such as volume-subpath
  • devcontainers/spec#511: no way to declare a read-only mount in object form
  • devcontainers/cli#881 and devcontainers/cli#1314: readonly is dropped when mounts are converted
Ngôn ngữ chính
TypeScript
Star
3k
Fork
473
Merge trung bình
10 giờ 31 phút
Pull request đã merge (30 ngày)
9

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của devcontainers/cli

Tất cả issue của devcontainers/cli

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.