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

However, the file is there:
$ which wine

The executable definitely is there and no dead symlink:
$ 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: -

It is a 32-bit ELF:
$ file /usr/bin/wine
/usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter /lib/, for GNU/Linux 2.6.32, 
BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped

I can get the dynamic section of the executable:
$ readelf -d /usr/bin/wine
Dynamic section at offset 0x1efc contains 27 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: []
 0x00000001 (NEEDED)                     Shared library: []
 0x00000001 (NEEDED)                     Shared library: []
 0x0000001d (RUNPATH)                    Library runpath: [$ORIGIN/../lib32]
 0x0000000c (INIT)                       0x7c000854
 0x0000000d (FINI)                       0x7c000e54
 [more addresses without file names]

However, I cannot list the shared object dependencies using ldd:
$ ldd /usr/bin/wine
/usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory

strace shows:
execve("/usr/bin/wine", ["wine"], 0x7fff20dc8730 /* 66 vars */) = -1 ENOENT (No such file or directory)
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 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

Even when only printing the possible values of LD_DEBUG, the error occurs instead
$ 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

What is the problem or what can I do to find out which file or directory is missing?

uname -a:

Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux


Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1


$ file /usr/bin/wine
/usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter /lib/, for GNU/Linux 2.6.32, 
BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped

Combined with this:
$ 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/ ELF interpreter. That is, this 64-bit system does not have any 32-bit compatibility libraries installed. Thus, @user1334609’s answer is essentially correct.

Method 2

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.

Method 3

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!!)

Problem on reboot:

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.

Method 4

FYI, I ran into this same issue running in an alpine-based docker image. The executable was a 64-bit ELF, and the alpine image was 64-bit, and the executable worked in a different container. So presumably the trimmed alpine libraries were not compatible with my executable. The node.js Docker hub page notes:

The main caveat [to running in the Alpine-based container] is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn’t have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

My solution was to use a different (e.g. Debian Jessie-based) container image.

All methods was sourced from or, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments