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/ld-linux.so.2, 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: [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]

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
  • does ./wine in /usr/bin work?
    – Aiden Bell
    Commented Jul 13, 2017 at 12:14
  • 1
    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...
    – akraf
    Commented Jul 13, 2017 at 12:32
  • 3
    Is /lib/ld-linux.so.2 present on your system? All symptoms point to it being missing, just checking. Commented Jul 13, 2017 at 14:22
  • 1
    @n.m. Yes, you were right. In fact, the whole directory /lib was missing :-)
    – akraf
    Commented Jul 14, 2017 at 10:01
  • 5
    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. Commented Jul 14, 2017 at 17:09

6 Answers 6



$ 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

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/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.

  • 6
    Is anyone going to talk about the misleading error message?
    – Rolf
    Commented Apr 22, 2020 at 10:55

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.

  • 1
    Please clarify how your solution resolve the case and answer the question Commented Jul 14, 2017 at 10:35
  • 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?
    – Jeff Schaller
    Commented Jul 14, 2017 at 10:41

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.

  • Thanks for connecting this originally sysadmin problem to the "new" world of containers!
    – akraf
    Commented Nov 30, 2019 at 23:29

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.

  • 1
    Small hint: When using systemrescuecd, I often just iterate over proc/sys/dev (for path in proc sys dev ; do mount -obind /$path /mnt/$path ; done) before doing the chroot. However if you're using the arch install iso, much easier to just run the provided arch-chroot executable as it does everything for you. Its in the arch-install-scripts package if someone wants to poke around. :)
    – zaTricky
    Commented Jul 15, 2017 at 9:42

For me, I was trying to run 32-bit application on a 64 bit operating system as mentioned by user1334609, so I needed to install 32-bit compatibility libraries. I'm on Ubuntu, so I did this:

dpkg --add-architecture i386
apt update
apt install libc6-i386

It worked and my elf file was able to find ld-linux. It then failed loading some libs, which I troubleshooted one by one.


FYI: I recently encountered the same error on some gcc-compiled files:

~/c_trials $ ./bb05
-bash: ./bb05: cannot execute: required file not found

I thought I had lost my mind... but then recalled:

I had recently moved this file (and the folder w/ all the files) from a Raspberry Pi 3 running bullseye to a Raspberry Pi 5 running bookworm.

After re-compiling on the RPi 5, everything was copacetic:

~/c_trials $ gcc -o bb05 bb05.c
~/c_trials $ ./bb05
blah, blah, blah

Lessons learned:

  1. All ARM machines are not created equal.
  2. Differences in glibc version may upset your apple cart.
  3. Error messages can be very misleading.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .