How can I resolve the error "cannot execute binary file"?

Question

When I login using SSH, all I can see is this...

-bash: /usr/bin/id: cannot execute binary file
-bash: [: : integer expression expected

I couldn't do anything in here. Commands such as halt, poweroff, reboot will return command not found.

How can I fix this? I am using Debian Squeeze Linux

the very last thing I did was install logwatch. Nothing else. — superuser, Jun 12 '12 at 21:33
can you `export PATH=/bin:/usr/bin:/sbin:/usr/sbin` ? Can the shell find halt/poweroff/reboot then? (Note, I'd advise not shutting down the system unless you know you can bring it back up, or have accepted that you might have to boot from a live-CD and fix everything manually) — Darth Android, Jun 12 '12 at 21:37
`PATH` is an environment variable which contains a list of folders which the shell searches for programs. `ls` for example, usually refers to `/bin/ls`, and your shell finds it by going through the folders listed in `PATH` one-by-one until it finds it, or if it doesn't find it in any of them, it gives up. I suppose a better starting point would be, what is the output of `echo $PATH` ? (edit: the `export` command is a way to define an environment variable in bash.) — Darth Android, Jun 12 '12 at 21:41
The reason I ask is because a few minutes ago, I wasn't even able to "poweroff" the machine. After doing "export PATH=/bin:/usr/bin:/sbin:/usr/sbin", it didn't do anything. So I tried "poweroff" again, and somehow it was able to be shutdown. — superuser, Jun 12 '12 at 21:44
Right now, it's pingable but not sshable. I'm just glad I have a backup of everything. — superuser, Jun 12 '12 at 21:47
Ah... I warned you not to shut the system down :P Can you get console access to it (physical monitor+keyboard attached)? Try booting the system in single-user mode (might be labelled as recovery mode) and see if you can get to a root shell. — Darth Android, Jun 12 '12 at 21:51
@David you won't see any output after typing `export PATH=/bin:/user/bin:/sbin:/usr/sbin`. It's a silent command. — Ben Richards, Jun 12 '12 at 21:57

score 124 · Accepted Answer · answered Jun 13 '12 at 03:07

124

Usually that error message means Linux doesn't recognize the file as a shell script or as an executable file.

Typically the cause is running an executable on the wrong architecture - if you try to run x86 executables on an ARM CPU, this message comes up.

Did /usr/bin/id get overwritten, possibly?

answered Jun 13 '12 at 03:07

LawrenceC

73,030
15
129
214

27

"if you try to run x86 executables on an ARM CPU, this message comes up." That was EXACTLY what caused it. Thanks everyone for your inputs! – superuser Jun 13 '12 at 04:18
It turned out my binary was a Windows exe file :P – forzagreen Dec 18 '18 at 13:39
2

How can we solve this? I am sure i get the same issue, but this answer does not really tell me a solution : / – Newskooler Mar 02 '19 at 20:08
To resolve, you need to use an ARM binary and not an x86 binary. If the source is available, you can recompile/rebuild under an ARM system. If the source is not available, check with the vendor for an ARM binary. The official JRE from Sun, for example, has both x86 and "embedded" or ARM versions. You have to use the ARM version. – LawrenceC Apr 21 '19 at 15:21
1

Wow, I have never see a vote count so high still perfectly balanced with the question! – IronEagle Apr 24 '23 at 01:37

score 42 · Answer 2 · answered Jun 13 '12 at 01:27

42

Try to run it using ./executablefilename instead of using sh executablefilename. It's not a shell script after all.

answered Jun 13 '12 at 01:27

RidDeBakTiYar

576
3
6
10

I had this problem when trying to run kiwix-serve on my raspberry pi. My overall solution I believe was to adjust the file permissions (it was not set to executable by anyone by default) and then ran it as `./kiwix-serve` – cchapman Jun 19 '18 at 15:38

score 16 · Answer 3 · edited Apr 07 '23 at 19:57

The problem is running a binary for a different processor architecture. You can use objdump (from binutils) to check architecture of binaries. You can use uname to check architecture of a machine.

e.g. I encountered this error "cannot execute binary file" when installing FF.Communicator - a firefox plugin for chrome (so I can run pages that use java applets).

objdump shows the binary is 64-bit elf64-x86-64

uname shows my machine is 32-bit i686

$ ./FF.Communicator 
bash: ./FF.Communicator: cannot execute binary file
$ uname -mpio
i686 i686 i386 GNU/Linux
$ objdump -a ./FF.Communicator 
./FF.Communicator:     file format elf64-x86-64
./FF.Communicator

objdump on a working binary on my machine shows it is 32-bit elf32-i386
```
$ objdump -a /bin/ls
/bin/ls:     file format elf32-i386
```

Using these tools you can check architectures of machines and binaries - not just intel architectures but any processor.

For Mac OSX users, you can find out the architecture info of a specific file using the "file" command:

$ file filename_here

score 7 · Answer 4 · answered Jun 12 '12 at 21:51

I'm making some wild guesses here, but it looks like the following is happening:

You log in over SSH, triggering bash to run your ~/.profile or ~/.bashrc to set up your environment for you (this is normal).
At some point it tries to execute /bin/id to get your uid, which fails, causing integer expression error, and terminating the script before it can set up your $PATH.
Because your $PATH is not set, bash is only able to run commands with the full path specified.

Use export PATH=/bin:/usr/bin:/sbin:/usr/sbin to fix the $PATH issue until you can fix the root cause of /bin/id failing.

score 5 · Answer 5 · answered Oct 24 '18 at 14:01

This means that you are trying to execute a binary file using your bash script which is not intended to be run as you trying it to be. It is already a binary file and you are trying your $SHELL to parse and run it.

in a very simple example, if you try to run `w' command like

$ bash w
/usr/bin/w: /usr/bin/w: cannot execute binary file

similarly you might be hitting the same method or as it looks from your code snippet.

While , for the remaining for your commands, Al these halt, shutdown , reboot etc commands are the root owned commands and need super-user prilveges to run and perform the required operation. normal users can't run them another explanation is that these commands are placed at /sbin/ and /usr/sbin , which might not be in your $PATH variable ( which is used to validate commands in your custody )

Well this is very possible explanation on docker/podman/container env when using `CMD`, thank you — Benyamin Limanto, Jan 19 '23 at 06:24

score 0 · Answer 6 · answered Jul 25 '18 at 08:43

0

You are running wrong version of the installer, for example, 64bit machine and trying to install 32bit version of the installer.

answered Jul 25 '18 at 08:43

kwai

11
1

score 0 · Answer 7 · answered Jun 12 '12 at 22:29

binary file consists of machine instructions the processor can understand. Your operating system does not mean the same executable will run. move back and forth between the processor instruction set compatible with will usually work well, if they are not compatible CPU will not be able to understand instructions.

How can I resolve the error "cannot execute binary file"?

7 Answers7

Linked

Related