"exec format error" and "cannot execute binary file": architecture and shebang mismatches

What it is

This is the kernel's ENOEXEC error from execve(2), described in its manual page as the executable having a recognized but unsupported format, or none at all. Bash reports it as cannot execute binary file: Exec format error; current Docker/runc as exec /usr/local/bin/app: exec format error (older releases: standard_init_linux.go:NNN: exec user process caused: exec format error); Python as OSError: [Errno 8] Exec format error. Two causes produce it, and a third, related one fails with a different message:

• Architecture mismatch: an ELF binary built for one CPU architecture (arm64, for example) is run on hardware for another (amd64) without an emulator registered through binfmt_misc.
• Missing or malformed shebang: a script has no #!interpreter first line, or something (such as a UTF-8 byte-order mark) precedes it. An interactive shell hides this case by running the file as a shell script itself; anything that calls execve directly (a container entrypoint, a subprocess call) gets ENOEXEC.
• CRLF line endings in the shebang: a trailing carriage return becomes part of the interpreter path, the kernel returns ENOENT instead, and the wording depends on the shell: bash 5.1 and older (and 5.3) print /bin/bash^M: bad interpreter: No such file or directory, bash 5.2 prints cannot execute: required file not found, and a #!/usr/bin/env bash line yields /usr/bin/env: 'bash\r': No such file or directory.

Why it matters

All three are common in cross-platform work: pulling a container image built for a different architecture than the host, copying scripts between operating systems, or generating a script with a tool that writes CRLF by default. The terse message does not say which cause applies.

How to apply

• Diagnose first: file ./target reports either the ELF architecture ("ELF 64-bit LSB executable, ARM aarch64") or, for a script, whether it has CRLF terminators. Compare an ELF's architecture against uname -m on the host, or against a container's target platform with docker image inspect <image> --format '{{.Architecture}}'.
• Fixes, least to most invasive:
  1. CRLF shebang: strip the carriage returns, e.g. sed -i 's/\r$//' script.sh or dos2unix script.sh.
  2. Missing/garbled shebang: add a correct first line, e.g. #!/usr/bin/env bash.
  3. Architecture mismatch in containers: request the right platform explicitly, docker run --platform linux/amd64 ..., or build for multiple platforms with docker buildx build --platform linux/amd64,linux/arm64 ... as Docker's multi-platform build documentation describes.
  4. Rebuild the binary natively for the target architecture instead of relying on emulation, especially for anything performance-sensitive.
• Not a fix: chmod +x alone does nothing for a format or architecture mismatch, though it is worth ruling out separately since a missing execute bit produces a different message ("Permission denied").

Pitfalls

• Assuming the message always means "wrong architecture" and rebuilding unnecessarily when the real cause is a CRLF shebang.
• Testing an arm64 image on amd64 under QEMU emulation and concluding it is fine: emulation is slow and has its own bugs, so a pass there does not prove the image behaves the same on real arm64 hardware.