„exec format error“ und „cannot execute binary file“: Architektur- und Shebang-Konflikte

Worum es geht

Dabei handelt es sich um den Kernel-Fehler ENOEXEC von execve(2). Die Manpage beschreibt ihn so, dass die ausführbare Datei ein erkanntes, aber nicht unterstütztes Format hat oder gar keines. Bash meldet ihn als cannot execute binary file: Exec format error, aktuelles Docker/runc als exec /usr/local/bin/app: exec format error (ältere Versionen: standard_init_linux.go:NNN: exec user process caused: exec format error), Python als OSError: [Errno 8] Exec format error. Zwei Ursachen lösen ihn aus; eine dritte, verwandte schlägt mit einer anderen Meldung fehl:

• Architektur-Konflikt: Eine ELF-Binärdatei, die für eine CPU-Architektur gebaut wurde (z. B. arm64), wird auf Hardware einer anderen Architektur (amd64) ausgeführt, ohne dass über binfmt_misc ein Emulator registriert ist.
• Fehlende oder fehlerhafte Shebang-Zeile: Einem Skript fehlt die erste Zeile #!interpreter, oder davor steht etwas anderes (etwa ein UTF-8-Byte-Order-Mark). Eine interaktive Shell verdeckt diesen Fall, indem sie die Datei selbst als Shell-Skript ausführt; alles, was execve direkt aufruft (ein Container-Entrypoint, ein Subprocess-Aufruf), erhält ENOEXEC.
• CRLF-Zeilenenden in der Shebang-Zeile: Das abschliessende Carriage Return wird Teil des Interpreterpfads, der Kernel liefert stattdessen ENOENT, und der Wortlaut hängt von der Shell ab: Bash 5.1 und älter (sowie 5.3) geben /bin/bash^M: bad interpreter: No such file or directory aus, Bash 5.2 gibt cannot execute: required file not found aus, und eine Zeile #!/usr/bin/env bash führt zu /usr/bin/env: 'bash\r': No such file or directory.

Warum es wichtig ist

Alle drei Fälle kommen in plattformübergreifender Arbeit häufig vor: wenn ein Container-Image für eine andere Architektur als die des Hosts gezogen wird, Skripte zwischen Betriebssystemen kopiert werden oder ein Skript mit einem Werkzeug erzeugt wird, das standardmässig CRLF schreibt. Die knappe Fehlermeldung verrät nicht, welche Ursache vorliegt.

So wird es angewendet

• Zuerst diagnostizieren: file ./target zeigt entweder die ELF-Architektur („ELF 64-bit LSB executable, ARM aarch64“) oder bei einem Skript, ob es CRLF-Zeilenenden hat. Die Architektur einer ELF-Datei mit uname -m auf dem Host vergleichen, bzw. mit der Zielplattform eines Containers über docker image inspect <image> --format '{{.Architecture}}'.
• Lösungen, von der am wenigsten bis zur am stärksten eingreifenden:
  1. CRLF in der Shebang-Zeile: die Carriage Returns entfernen, z. B. mit sed -i 's/\r$//' script.sh oder dos2unix script.sh.
  2. Fehlende oder fehlerhafte Shebang-Zeile: eine korrekte erste Zeile ergänzen, z. B. #!/usr/bin/env bash.
  3. Architektur-Konflikt bei Containern: die passende Plattform ausdrücklich anfordern mit docker run --platform linux/amd64 ... oder für mehrere Plattformen bauen mit docker buildx build --platform linux/amd64,linux/arm64 ..., wie es die Dokumentation von Docker zu Multi-Platform-Builds beschreibt.
  4. Die Binärdatei nativ für die Zielarchitektur neu bauen, statt sich auf Emulation zu verlassen, besonders bei allem, was leistungskritisch ist.
• Keine Lösung: chmod +x allein bewirkt bei einem Format- oder Architektur-Konflikt nichts. Es lohnt sich dennoch, das separat auszuschliessen, da ein fehlendes Ausführungsrecht eine andere Meldung erzeugt („Permission denied“).

Stolpersteine

• Annehmen, die Meldung bedeute immer „falsche Architektur“, und unnötig neu bauen, obwohl die eigentliche Ursache eine CRLF-Shebang-Zeile ist.
• Ein arm64-Image auf amd64 unter QEMU-Emulation testen und daraus schliessen, es sei in Ordnung: Emulation ist langsam und hat eigene Fehler, ein erfolgreicher Lauf beweist daher nicht, dass sich das Image auf echter arm64-Hardware gleich verhält.