Summary
The devcontainer generated by mxcli init / mxcli new (template in cmd/mxcli/tool_templates.go) has two independent bugs in its postCreateCommand that make the container's post-create step fail (VS Code shows a red error) when the workspace is a bind-mount from a Windows drive under Podman.
The container itself builds and works — mxcli runs fine, the binary is -rwxrwxrwx and executable — but postCreateCommand exits non-zero, so VS Code marks the whole setup as failed.
Environment
- Windows 11 + WSL2 + Podman 5.8.2
- Devcontainer for a Mendix project on
C:\Mendix\...
- Workspace bind-mounted via 9p into the Podman machine (
/mnt/c), then into the container
- Base image:
mcr.microsoft.com/devcontainers/base:bookworm
mxcli v0.14.0
Symptoms (from the container log)
command not found: file
chmod: changing permissions of './mxcli': Operation not permitted
Bug 1 — file is not installed in the image
postCreateCommand runs:
if [ -f ./mxcli ] && file ./mxcli | grep -q Linux; then echo 'mxcli binary OK'; else ...download...; fi
But the Dockerfile's apt install list (cmd/mxcli/tool_templates.go, the generateDockerfile main apt-get install) is:
wget apt-transport-https gpg ca-certificates curl temurin-21-jdk nodejs postgresql-client kafkacat
There is no file. So file ./mxcli emits command not found, the pipeline fails, the fast-path (mxcli binary OK) is never taken, and the command always falls through to the download branch even when a valid Linux binary is already committed. Wasteful, and it sets up Bug 2.
Fix: add file to the Dockerfile apt install list so the Linux-binary check works as intended.
Bug 2 — unguarded chmod +x ./mxcli fails on a 9p bind-mount
The download fallback branch ends with:
curl -fsSL .../mxcli-linux-${ARCH} -o ./mxcli && chmod +x ./mxcli
On a 9p filesystem (Windows drive bind-mounted through the Podman machine), Unix permission changes are not permitted, so chmod fails with Operation not permitted. The binary is already executable (9p exposes it -rwxrwxrwx), so the chmod is unnecessary — but its non-zero exit propagates and fails the entire postCreateCommand.
Fix: guard the chmod so it can't fail the step:
chmod +x ./mxcli 2>/dev/null || true
Proposed diff
cmd/mxcli/tool_templates.go:
postCreateCommand — guard the chmod:
-... && curl -fsSL https://github.com/mendixlabs/mxcli/releases/latest/download/mxcli-linux-${ARCH} -o ./mxcli && chmod +x ./mxcli; }; fi
+... && curl -fsSL https://github.com/mendixlabs/mxcli/releases/latest/download/mxcli-linux-${ARCH} -o ./mxcli && { chmod +x ./mxcli 2>/dev/null || true; }; }; fi
Dockerfile apt list — install file:
apt-get install -y --no-install-recommends \
temurin-21-jdk \
nodejs \
postgresql-client \
+ file \
kafkacat \
Both fixes are independent; together they make mxcli init/new devcontainers work cleanly on Podman-on-Windows with a Windows-drive workspace.
Related
Summary
The devcontainer generated by
mxcli init/mxcli new(template incmd/mxcli/tool_templates.go) has two independent bugs in itspostCreateCommandthat make the container's post-create step fail (VS Code shows a red error) when the workspace is a bind-mount from a Windows drive under Podman.The container itself builds and works —
mxcliruns fine, the binary is-rwxrwxrwxand executable — butpostCreateCommandexits non-zero, so VS Code marks the whole setup as failed.Environment
C:\Mendix\.../mnt/c), then into the containermcr.microsoft.com/devcontainers/base:bookwormmxcliv0.14.0Symptoms (from the container log)
Bug 1 —
fileis not installed in the imagepostCreateCommandruns:But the Dockerfile's apt install list (
cmd/mxcli/tool_templates.go, thegenerateDockerfilemainapt-get install) is:There is no
file. Sofile ./mxcliemitscommand not found, the pipeline fails, the fast-path (mxcli binary OK) is never taken, and the command always falls through to the download branch even when a valid Linux binary is already committed. Wasteful, and it sets up Bug 2.Fix: add
fileto the Dockerfile apt install list so the Linux-binary check works as intended.Bug 2 — unguarded
chmod +x ./mxclifails on a 9p bind-mountThe download fallback branch ends with:
On a 9p filesystem (Windows drive bind-mounted through the Podman machine), Unix permission changes are not permitted, so
chmodfails withOperation not permitted. The binary is already executable (9p exposes it-rwxrwxrwx), so thechmodis unnecessary — but its non-zero exit propagates and fails the entirepostCreateCommand.Fix: guard the chmod so it can't fail the step:
Proposed diff
cmd/mxcli/tool_templates.go:postCreateCommand — guard the chmod:
Dockerfile apt list — install
file:apt-get install -y --no-install-recommends \ temurin-21-jdk \ nodejs \ postgresql-client \ + file \ kafkacat \Both fixes are independent; together they make
mxcli init/newdevcontainers work cleanly on Podman-on-Windows with a Windows-drive workspace.Related