I'm trying to run a program, but it gives an error:

bash: ./program: cannot execute binary file: Exec format error

The result of file program was:

program: ELF-32-bit LSB executable, ARM, EABI4 version 1 (SYSV), dynamically linked (uses share libs), for GNU/LINUX 2.6.16, not stripped

How can I fix this?

I'm using Ubuntu 14.04.2 (amd64) with VMware. I also tried using Ubuntu i386, but the result was the same.

  • 7
    It's an ARM executable, i.e. you downloaded the wrong executable format or compiled for the wrong platform. You have to get the right executable or recompile. Jul 15, 2015 at 9:24

9 Answers 9


You're trying to run an executable compiled for an ARM architecture on an x86-64 architecture, which is much like asking your processor who only speaks English to take directions in Chinese.

If you need to run that executable you have two choices:

  1. Get an x86-64 version of the executable (by any mean; if you're unable to get an x86-64 version of the executable but you're able to get its source code, you can try to recompile it on the virtual machine);

  2. Install Ubuntu Server for ARM in place of Ubuntu 14.04.2 (amd64). This requires either a physical machine running on an ARM architecture or a virtualization software that can emulate it.

  • While the answer seems to be full-fledge, I tried to speak to my processor in English, but it arrogantly ignores me and doesn't reply anything :(
    – mathway
    Apr 23, 2021 at 20:07

This can also occur if you attempt to run an x86-64 executable on a 32-bit platform.

In one specific instance, I downloaded Visual Studio Code and tried to run it on my Ubuntu installation, but I hadn't realized that I had installed 32-bit Ubuntu in this VM. I got this error, but after downloading the 32-bit version, it ran without issue.


It is often possible to run an ARM executable image on an amd64 system if you install the binfmt-support, qemu, and qemu-user-static packages:

sudo apt install binfmt-support qemu qemu-user-static

qemu will then perform syscall emulation when you run the executable. This works for most ARM binaries but there are a few that may not run correctly.

  • sudo apt-get install binfmt-support qemu qemu-user-static
    – Gun2sh
    Jul 5, 2017 at 18:38
  • After install, was able to execute with /usr/bin/arm-linux-gnueabi-gcc -mfpu=neon -mcpu=cortex-a9 -mfloat-abi=softfp main.c -static
    – phoxd
    Jun 12, 2021 at 7:00

Such error may occur if all of the following are true:

  • Executable is not a file but a link
  • You run run it inside VM
  • File is located in shared folder
  • Your host is Windows.

If you got that file, let's say, in archive - try to unpack it inside VM, in some directory inside virtual drive, not folder mapped to your host machine hard drive, for example /myNewDir/

  • 1
    That's pretty helpful. For me, I created a shortcut (link) to that executable file, then executing the shortcut gave me the error.
    – Duc Tran
    Mar 30, 2018 at 20:57

If more than one java is installed on the system this might happen and not set as default. On Ubuntu14.04 LTS I could get it resolved by executing following and choosing the java I needed.

sudo update-alternatives --config java
[sudo] password for user: 
update-alternatives: warning: /etc/alternatives/java has been changed (manually or by a script); switching to manual updates only
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
  0            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      auto mode
  1            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      manual mode
  2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1069      manual mode

Press enter to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java to provide /usr/bin/java (java) in manual mode

I choose 2 and set openjdk-8 as a default. Which did not show the Exec format error.


You must compile your file using an appropriate CPU architecture (x86 for example) and copy the .exe file on your linux machine. Then you can install mono on your linux machine and issue the following command:

mono myprogram.exe
  • 1
    The OP wasn't using a .exe file, but a native Linux executable. Also, Mono won't run all Windows executables - it's designed to replace the Microsoft.NET Framework (I think it's kinda compatible with modern .NET too but I'm not sure). If you want to run arbitrary Windows programs on Linux, you need Wine, not just Mono.
    – ArrayBolt3
    Jul 22 at 6:17

This can also happen if the binary uses a libc implementation which is not libc, such as musl. These days this specific problem is most likely encountered when trying to run a binary with libc in a Docker container with an image based on alpine. There is nothing that can be done to the binary itself to support both environments, because the libc implementation must always be linked statically, i.e. built directly into the binary, for reasons.


I got this error trying to run a zip file containing an executable rather than extracting it and running the executable itself xD

In addition to the other answers offered here, I suppose there would be a lot of file types that aren't intended to be executable which could cause this error.

  • Those would usually not have the x bit set in the chmod permissions, so you would get a different error message ("Permission denied"). Only actually executable files should be marked executable, obviously.
    – tripleee
    Jul 2, 2020 at 8:07

This is another special case: WSL (Windows Subsystem for Linux) by default(!) only supports 64bit executables. I think this is a rather unusual behaviour, as normally there is a backwards compatibility.

(Even more special is that selecting 64bit in a formerly 32bit project of Windev won't fix your issue. You need to start a new project, selecting 64bit right in the beginning. Tested on Windev 26. This IDE sucks, forced to use it because of working legacy code.)

  • 2
    You are wrong ,,, it is a case of trying to run an ARM executable on an AMD/Intel system.
    – Soren A
    Jul 22 at 1:34
  • @SorenA I changed my answer according to superuser.com/a/1407818 I still consider it valueable, as recompiling a program as 64bit fixed that issue for me
    – PythoNic
    Jul 27 at 14:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.