Cannot execute binaries in Ubuntu : file not found
When I try to run any executable file a file not found error occurs. Sometimes it says nothing but doesn’t do anything. For example, when I execute ./blah-blah.bin it fails finding the file when it is clearly there. When I execute ./blah-blah-file-2.sh , it is silent. Note 1: files have +x.
Note 2: root also cannot execute.
Note 3: everything from /usr/bin executes.
Note 4: I can’t try it from GUI, I have only access to its console. What’s the problem? Upd: suddenly some commands (e.g. ls ) begin fail with a file not found . They worked yesterday.
Please post the first couple of lines of that file (I’m betting it doesn’t contain the #! path to a valid shell).
./alfresco-install.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
You wouldn’t happen to be trying to execute a 32bit binary on a 64bit OS without 32bit support packages? Without the ia32 libs you wouldn’t get very far on AMD64.
3 Answers 3
and check the output. This sounds suspiciously like it’s missing a dynamic library or two.
This solved my problem. I had the same issue where executing a file would just produce «not found» as if the file couldn’t be found. Using this I found out that it was trying to load a library that didn’t exists.
Check the mount options, specifically, whether it is mounted noexec.
If this is the problem, e.g. on /tmp, do
sudo mount -o remount,exec /tmp @Alexey: ahem.
Is it a script or a binary executable?
If it’s a script, check the #! line.
Depending on your shell, the error message for a command with a bad #! line can refer to the script rather than to the missing interpreter.
% cat foo #!/bin/no_such_interpreter echo hello % chmod +x foo % ./foo ./foo: Command not found. % Using bash, the error message is different:
$ chmod +x foo $ cat foo #!/bin/no_such_interpreter echo hello $ ./foo bash: ./foo: /bin/no_such_interpreter: bad interpreter: No such file or directory $ Even if the #! line looks ok, it can fail if there’s a \r character at the end of the line, which can often happen if the file was created on Windows. What does
head -1 blah-blah.bin | cat -A If that doesn’t solve the problem, show us exactly what command you typed and the error message that resulted.
EDIT : I realize your title suggests it’s a binary executable. Exactly what kind of file is it? What is the output of
Linux executable fails with «File not found» even though the file is there and in PATH
I want to launch the wine executable (Version 2.12), but I get the following error ( $ =shell prompt):
$ wine bash: /usr/bin/wine: No such file or directory $ /usr/bin/wine bash: /usr/bin/wine: No such file or directory $ cd /usr/bin $ ./wine bash: ./wine: No such file or directory $ stat /usr/bin/wine File: /usr/bin/wine Size: 9712 Blocks: 24 IO Block: 4096 regular file Device: 802h/2050d Inode: 415789 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-07-13 13:53:00.000000000 +0200 Modify: 2017-07-08 03:42:45.000000000 +0200 Change: 2017-07-13 13:53:00.817346043 +0200 Birth: - $ file /usr/bin/wine /usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped $ readelf -d /usr/bin/wine Dynamic section at offset 0x1efc contains 27 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libwine.so.1] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000001d (RUNPATH) Library runpath: [$ORIGIN/../lib32] 0x0000000c (INIT) 0x7c000854 0x0000000d (FINI) 0x7c000e54 [more addresses without file names] $ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory execve("/usr/bin/wine", ["wine"], 0x7fff20dc8730 /* 66 vars */) = -1 ENOENT (No such file or directory) fstat(2, ) = 0 write(2, "strace: exec: No such file or di". 40strace: exec: No such file or directory ) = 40 getpid() = 23783 exit_group(1) = ? +++ exited with 1 +++ Edited to add suggestion by @jww: The problem appears to happen before dynamically linked libraries are requested, because no ld debug messages are generated:
$ LD_DEBUG=all wine bash: /usr/bin/wine: No such file or directory $ LD_DEBUG=help wine bash: /usr/bin/wine: No such file or directory Edited to add suggestion of @Raman Sailopal: The problem seems to lie within the executable, as copying the contents of /usr/bin/wine to another already created file produces the same error
root:bin # cp cat testcmd root:bin # testcmd --help Usage: testcmd [OPTION]. [FILE]. Concatenate FILE(s) to standard output. [rest of cat help page] root:bin # dd if=wine of=testcmd 18+1 records in 18+1 records out 9712 bytes (9.7 kB, 9.5 KiB) copied, 0.000404061 s, 24.0 MB/s root:bin # testcmd bash: /usr/bin/testcmd: No such file or directory Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux Arch is multilib-capable. Multilib repository is enabled in /etc/pacman.conf . All dependencies of the wine package are installed. However, reinstalling them just to make sure.
Experience 😉 when you try to run an executable and get a «file not found» error while the file is obviously right here, it’s the interpreter missing. Your file command shows what interpreter is set for this executable.
5 Answers 5
$ file /usr/bin/wine /usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped $ ldd /usr/bin/wine /usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory Strongly suggests that the system does not have the /lib/ld-linux.so.2 ELF interpreter. That is, this 64-bit system does not have any 32-bit compatibility libraries installed. Thus, @user1334609’s answer is essentially correct.
You are trying to run 32-bit application on a 64 bit operating system, so you need to install 32-bit compatibility libraries (glibc in particular) before this can work.
What Romeo said; you would run apt-get on an arch-linux system, instead of pacman? And how would compression libraries and ncurses help them?
OK, I was busy for the last eight hours to get my system up and running again after CPU overheating shut-down. On reboot it became apparent that it was so screwed up that even the fall-back console of initrd didn’t recognize my keyboard anymore. It is a mystery for me how the system managed to stay operative for so long, while I was trying to implement the countless suggestions by you (thank you a lot!!)
Warning: /lib/modules/4.11.3-1-ARCH/modules.devname not found - ignoring ERROR: device 'UUID=. ' not found. Skipping fsck. ERROR: Unable to find root device 'UUID=. '. You are being dropped to a recovery shell Type 'exit' to try and continue booting sh: can't access tty: job control turned off and no keyboard working afterwards 🙂
The Problem was: An update replaced the symlink /lib -> /usr/lib with a directory. So that meant all libraries and kernel modules, which are expected to be in /lib were missing 🙂
So I recreated the symlink and reinstalled the base system from a live CD.
Now that I have internet again, I also found this thread
I also used the package manager of my bricked on-disk installation (called pacman ) from the live CD to reinstall all the packages of the base group (maybe only the kernel, so package linux would have been enough, I don’t know)
To accomplish that, mount the main partition of the bricked installation to the /mnt directory of the live CD system and use chroot to make pacman think /mnt is / (insert your bricked system’s main partition for sdXXX )
mount /dev/sdXXX /mnt # Recreate the /lib -> usr/lib symlink ln -s usr/lib /lib # Mount essential system folders also to the respective subfolders of /mnt mount -t proc proc /mnt/proc mount -t sysfs sys /mnt/sys mount -o bind /dev /mnt/dev # Fake /mnt to be /, so that pacman installs the packages to the correct places chroot /mnt # Reinstall the Arch Linux base system pacman -Sy base For the record: create a relative symlink, so ln -s usr/lib /mnt/lib and not ln -s /usr/lib /mnt/lib , because during early system boot (initrd stage) the main partition will be mounted first to /new_root . Would the symlink be absolute, you would get the above-mentioned error during early boot.
Linux error file not found
The problem you are facing is this: Recently, you have upgraded your installation of Linux to a newer version. You have recycled your home directory, as it contains many useful programs and games. However, since the upgrade these programs no longer work. When you try to run then, you get the file not found error.
You may suspect you are facing permissions and file attributes problems, like the executable bit, but you can obviously see that it’s not that. Something else is afoot, and you’re not quite sure what to do. This short tutorial will teach you how to approach problems revolving around executable binaries and making them work again.
Problem
As mentioned earlier, you are facing a silly situation. Let’s say you have a game, like Enemy Territory Quake Wars, which worked marvelously on Lucid, but now seems to stutter on Pangolin. And by stutter, I mean, it won’t start at all. Yes, you did your homework, the file has the proper 755 permission, it’s where it ought to be.
But for some reason, the shell throws the file not found error. And no, you’re not having any BASH problems ethers, because other stuff and some custom script or even other programs and games work just fine. So what now?
Resolution
You need to figure what’s wrong. The best way to handle binary files is to figure out if there’s anything wrong with these files. To that end, you will want to use the file command, which we mentioned in my Linux cool hacks tutorials, all four of them, links below.
If the command returns output that reads ELF something executable, you are ok. But then, read the whole thing. Is this a 32-bit or a 64-bit executable? Is it dynamically linked, that is, does it use shared libs?
This will give you the direction you need. If you’re using 32-bit libs on 64-bit systems, this might be the problem you’re facing. Moreover, if the binary uses shared libraries, then you will want to use the ldd command to check whether the binary is linked correctly.
All right, let’s see what ldd reports:
But that’s not true. We know this is a dynamically linked executable. We know that it used to work just fine in previous versions of our operating system. And yes, please verify that you’re not running ldd against a wrapper script, because it is not an executable.
So what now? The answer is: If the system reports an executable is not an executable, you are most likely missing the correct version of libraries, all of them, for your binary. Most importantly, you’re missing the right version of GLIBC too. This usually happens when you try to run 32-bit programs on 64-bit systems.
Install 32-bit libc libraries
We do that — example shown on Linux Mint 13 Maya:
sudo apt-get install libc6:i386
Next, we check our binary again with ldd — voila:
More reading
As promised, some useful articles that will help you become more of a geek:
Cool hacking tutorials — parts one, two, three, and four
Linux debugging super tutorial
Conclusion
There you go, short, simple and handy. This guide teaches you not only how to overcome a small nuisance resulting from an upgrade, but it also highlights the way of thinking and isolating your problems. We used a small number of commands, like file and ldd, and yet we gained an abundance of information that helped narrow down the issue and come with a quick solution.
You get a bit of everything here, system upgrade woes, figuring out permissions, checking file type, architecture and linking, correlating to ldd output before and after the upgrade, installing several libraries, and doing all of that from the command line. Plus you get a wealth of tips and tricks listed in six other tutorials, all of which should help you master your Linux box and gain additional confidence in resolving system issues. That would be all.