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

Offen
  • Stimmt etwas nicht?
#1,352 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@agmitron arbeitet bereits daran.

Seit 06.11.2026.

  • #1353 von @agmitron — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
docker, docker-compose, typescript
Bereich
cli, devtools

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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
Vorherrschende Sprache
TypeScript
Sterne
3k
Forks
473
Ø Merge
10 Std. 31 Min.
Gemergte PRs (30 T.)
9

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus devcontainers/cli

Alle Issues in devcontainers/cli

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.