Revision 1 — the current text. The evidence on this page is this revision’s own — it has not been carried forward from, or to, any other revision.
Checks the image's recorded architecture against the host's before assuming a CPU mismatch, fixes it with a multi-arch build, and verifies. If architectures already match, it falls back to the second real cause of this exact message: a script whose shebang line is missing or corrupted (commonly by CRLF line endings). It does not cover exec format error thrown by a genuinely corrupted or truncated binary unrelated to architecture or shebangs.
Unverifiedno reproductions yetWhy this confidence?8 steps, exactly as this revision published them.
This is the kernel refusing to execute a binary it doesn't understand — usually because the binary was compiled for a different CPU architecture than the host it's running on.
What happens next
Compare what architecture the image was built for against the architecture of the host that's failing.
docker image inspect <image>:<tag> --format '{{.Architecture}}'
uname -mExpected result
amd64
aarch64What happens next
The image's architecture doesn't match the host's — rebuild for the architectures you actually deploy to instead of relying on the builder host's default.
Changes system or service state. Review before running.
Builds and pushes a new multi-architecture manifest for this tag to the registry. Anything already running from the old single-arch tag is unaffected until it's redeployed, but new pulls of this tag now resolve to the matching architecture automatically.
docker buildx build --platform linux/amd64,linux/arm64 -t <image>:<tag> --push .What happens next
Architectures already match, so check whether the entrypoint is an interpreted script with a missing or corrupted shebang line — the kernel returns exactly the same exec format error when it tries to exec a script directly instead of handing it to an interpreter. A common cause is CRLF line endings: a stray \r right after #!/bin/sh corrupts the interpreter path.
docker run --rm --entrypoint sh <image>:<tag> -c "head -c 100 /path/to/script | cat -A"Expected result
#!/bin/sh^M$
echo "starting"^M$What happens next
Run the image on the previously-failing host (or have it redeployed there) to confirm the fix actually resolved it.
docker run --rm <image>:<tag> <command>Expected result
(container starts and runs normally)What happens next
The ^M markers are carriage returns from CRLF line endings, most often introduced by editing the script on Windows or a misconfigured git autocrlf setting. Ensure the file starts with a valid shebang (#!/bin/sh or #!/usr/bin/env bash) and has Unix (LF) line endings — dos2unix <script>, or a .gitattributes entry marking the file text eol=lf, fixes it.
Architecture matches and the entrypoint's shebang looks fine — check the full error line for the exact path the kernel tried to exec, and confirm that file actually has the executable bit set (chmod +x) inside the image.
The container now runs correctly on the target architecture.
What would strengthen it: 6 more independent reproductions. Reproductions from 3 more distinct environments.
This counts only what was recorded against revision 1 itself. Nothing reported against another revision is included here — see the revision history for why.