exec format error: The binary is for a different architecture or is not an executable at all

The kernel refused to execute the file because it does not recognise its format — almost always an architecture mismatch, or a script with no shebang being run as a binary.

Applies to: All Kubernetes versions, Linux nodes

What it means

exec format error is ENOEXEC: the kernel examined the file's header and found nothing it can run. In containers this has two dominant causes. The first is architecture: an arm64 binary on an amd64 node, or the reverse, which happens routinely when images are built on a developer machine with a different processor than the cluster. The second is a script without a shebang line — the kernel has no interpreter to hand it to, so it refuses. A related variant is a script whose shebang is correct but whose line endings are CRLF, making the interpreter path include a carriage return that does not exist.

Most common causes

• An image built for a different CPU architecture than the node — commonly an arm64 image built on a modern laptop running on amd64 nodes.
• A single-architecture image in a cluster with mixed node architectures.
• A script with no shebang line invoked directly as a command.
• A shebang with Windows line endings, so the interpreter path is not found.
• A file that is not an executable at all, such as a text file or an archive.
• A corrupted binary, from a truncated build artefact or a failed copy.

How to diagnose it

1. Check the image's platforms against the node: docker manifest inspect IMAGE lists what architectures it provides.
2. Check the node's architecture: kubectl get node NODE -o jsonpath='{.status.nodeInfo.architecture}'.
3. If the pod runs on some nodes and not others, a mixed-architecture cluster is confirmed.
4. Inspect the file inside the image: file /path/to/binary reports its architecture and type.
5. Check the shebang: head -1 script.sh | cat -A reveals a trailing ^M.

How to fix it

1. Build multi-architecture images so one tag serves every node type. This is the durable fix for mixed clusters.
2. Alternatively, pin the workload to matching nodes with a node selector on kubernetes.io/arch.
3. Add a shebang to scripts, or invoke them through their interpreter explicitly.
4. Normalise line endings so shell scripts are checked out and built with LF.
5. Rebuild if the binary is corrupted, and verify artefact integrity in the build pipeline.

Notes

In a mixed-architecture cluster this failure is intermittent by node, so the same deployment succeeds and fails depending on scheduling. The kubernetes.io/arch label on the failing pods' nodes is the fastest confirmation.

Related

• Exit code 127 — Command not found
• RunContainerError — The container was created but failed to start

Sources

• Kubernetes documentation — Images: image architecture
• Kubernetes documentation — Assigning Pods to Nodes
• OCI Runtime Specification