I've downloaded a game (Shank) but the bin file doesn't run. The error that is shown when I try to launch the executable is:

bash: ./shank-linux-120720110-1-bin: No such file or directory
  • 4
    Maybe "chmod u+x ./shank*bin" first?
    – agent86
    May 7, 2012 at 19:35
  • 2
    also shouldn't that be '.bin' rather than '-bin', maybe it's just a typo
    – Anake
    May 7, 2012 at 20:25
  • Thank you for your reply. I've done the command you said Agent86 but I have the same result. I've downloaded also the .deb file but there is a problem too. I don't know what problem has this game.
    – Francesco
    May 7, 2012 at 21:29
  • Please confirm whether you're running a 64-bit installation (that's the most common case for this problem). May 7, 2012 at 21:49
  • 2
    @agent86: No. In that case the error message would be "Permission denied". May 24, 2017 at 6:42

9 Answers 9


You're probably trying to run a 32-bit binary on a 64-bit system that doesn't have 32-bit support installed.

There are three cases where you can get the message “No such file or directory”:

  • The file doesn't exist. I presume you've checked that the file does exist (perhaps because the shell completes it).
  • There is a file by that name, but it's a dangling symbolic link.
  • The file exists, and you can even read it (for example, the command file shank-linux-120720110-1-bin displays something like “ELF 32-bit LSB executable …”), and yet when you try to execute it you're told that the file doesn't exist.

The error message in this last case is admittedly confusing. What it's telling you is that a key component of the runtime environment necessary to run the program is missing. Unfortunately, the channel through which the error is reported only has room for the error code and not for this extra information that it's really the runtime environment that's to blame. If you want the technical version of this explanation, read Getting “Not found” message when running a 32-bit binary on a 64-bit system.

The file command will tell you just what this binary is. With a few exceptions, you can only run a binary for the processor architecture that your release of Ubuntu is for. The main exception is that you can run 32-bit (x86, a.k.a. IA32) binaries on 64-bit (amd64, a.k.a. x86_64) systems.

In Ubuntu up to 11.04, to run a 32-bit binary on a 64-bit installation, you need to install the ia32-libs package Install ia32-libs. You may need to install additional libraries (you'll get an explicit error message if you do).

Since 11.10 (oneiric) introduced multiarch support, you can still install ia32-libs, but you can choose a finer-grained approach, it's enough to get libc6-i386 Install libc6-i386 (plus any other necessary library).

  • Thanks for a great answer, Gilles. While I haven't experienced this problem (yet!), I have filed your answer away for future reference.
    – Jim C
    May 7, 2012 at 21:56
  • Thank you for your exhaustive answer! The file bin I've downloaded was the only one available in this format(bin). So i think is good for all architectures. I've also downloaded the .deb file for my architecture (64bit) but with different error. At this point I think that the game is affected by some bugs or I don't be able to install this game. Now I try to download libc6-i386 and I still try to install it. I will write again if there are significant changes. Thank you for you time.
    – Francesco
    May 7, 2012 at 22:08
  • 5
    @Francesco Please do post the solution! It is likely to help other people trying to run Shank on Ubuntu. It's perfectly ok to answer your own question. May 9, 2012 at 18:19
  • 1
    You can use ldd to check if you're missing a library. ldd kgio_ext.so might say something like libruby.so.2.3 => not found among others Feb 3, 2016 at 22:45
  • 1
    There's apparently another scenario when bash: ...some...path...: No such file or directory can show up: after moving the executable file. Bash seems to cache paths to executables found in $PATH; run hash -r to clear it. See: unix.stackexchange.com/a/5610/11352
    – akavel
    Dec 12, 2016 at 11:25

64 bit Ubuntu Multiarch systems

Follow this answer only if the output of file file-name shows,

file-name: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped

To run 32bit executable file in a 64 bit multi-arch Ubuntu system, you have to add i386 architecture and also you have to install libc6:i386,libncurses5:i386,libstdc++6:i386 these three library packages.

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386
  • I would use sudo for the last command : launching a 32bit binary (so obviously not compiled by you or Ubuntu) as sudo could be risky. (well, even as non root, admitedly)
    – alci
    May 7, 2014 at 16:58
  • what ever it may be at the last but it works. May 7, 2014 at 17:01
  • 1
    Is should be noted that if you are using CentOS or RedHat, this answer does not apply. Was thrown off for a few hours because of this.
    – omikes
    Feb 28, 2017 at 23:26
  • 1
    On Kali 2 64 bit, I only had to install libselinux1:i386
    – Aralox
    Mar 19, 2017 at 10:57
  • FWIW, this worked like a charm for me on Raspberry Pi OS 64-bit (Debian Buster derived), substituting "armhf" for "i386". Thanks!
    – Ivan X
    Aug 21, 2023 at 4:43

To expand on @Gilles answer, there are at least three scenarios resulting in this error:

  1. The file doesn't exist.
  2. The file exists but is a dangling symbolic link.
  3. The file exists (e.g. file command works), making for a puzzling error message. This may mean there's a problem with the loader.

Categories of loader problems:

  1. An executable's loader does not exist. You can check this using the file command and see if the loader does exist. E.g.

    file lmgrd
    lmgrd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-lsb-x86-64.so.3, for GNU/Linux 2.6.18, stripped

    Notice interpreter /lib64/ld-lsb-x86-64.so.3; if this file does not exist, you need to install it. For this particular loader on 16.04, the answer turned out to be sudo apt-get install lsb.

  2. Issues with a script's loader (see this answer).

  3. Missing shared libraries -- use ldd <file-name> to check for any "not found" libraries. See this answer for more info.

The loader not existing could be due to a 32/64 bit mismatch or some other reason. There might be other kinds of loader errors I don't know about.

  • 4
    In my case, file lmutil didn't show the interpreter, but ldd did, and installing lsb solved the problem.
    – davidA
    Jun 24, 2018 at 23:05
  • 2
    Ran into this additional class of errors trying to run Node 4.9.1 on an Alpine linux docker image, I had to install libc6-compat to get the interpreter /lib64/ld-linux-x86-64.so.2 to load. Thanks for the addition! Mar 26, 2021 at 17:42
  • This fixes the "Deadline License Server not starting" issue on Ubuntu 20.04
    – Xedret
    Jun 25, 2021 at 3:54
  • lmgrd was the exact binary I was having problems with, thank you!
    – Sandwich
    Apr 22, 2022 at 16:38
  • 1
    Crazy, I think we are debugging the same executable. lmutil and lmgrd ...MOE license manager? Or is this a generic license manager underneath. Aug 2, 2023 at 21:16

Here's a transcript showing a bit more about the nature of the problem, and how to fix it as of Ubuntu 16.04. Notice that even though file reports "dynamically linked", ldd reports "not a dynamic executable".

$ ./myprogram
bash: myprogram: No such file or directory

$ file myprogram
myprogram: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped

$ ldd myprogram
    not a dynamic executable

Once you install libc6:i386, things start improving...

$ sudo apt-get install libc6:i386 # the initial fix

$ ldd myprogram
    linux-gate.so.1 =>  (0xf77fd000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7626000)
    /lib/ld-linux.so.2 (0x56578000)

$ ./myprogram
myprogram: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

To complete the job, you may need to identify and install additional libraries one at a time...

$ sudo apt-get install libstdc++6:i386 ## may require various additional libs

$ ./myprogram
... works correctly ...

I don't know if there is a systematic way of identifying the correct libraries to install. There is a bit of guesswork mapping the error messages to package names (tab completion helps).

  • ldd (incorrectly) reports "not a dynamic executable". Jun 9, 2016 at 15:42

By installing the deb for 32 bit I realized I was missing some libraries (in addition to ia32-libs and libc6). I first solved this problem by giving this command:

sudo apt-get install -f          

Then I got another error:

Message: SDL_GL_LoadLibrary 
Error: Failed loading libGL.so.1

Obviously, these libraries were properly installed. Without going into details I had to link the libraries by hand. I realized then that could also an easier solution through Synaptic install the following packages:

libgl1-mesa-dri: i386.

After that the next problem was the black screen while playing, which I solved by replacing the executable in /Shank/bin with this: http://treefort.icculus.org/smb/smb-linux-mesa-hotfix-test.tar.bz2.

I hope it will be useful to someone. If you need more help or more details please feel free to contact me.


This error happens when working on Windows (which introduces extra characters because of different line separator than Linux system) and trying to run this script (with extra characters inserted) in Linux. The error message is misleading.

In Windows, the line separator is CRLF (\r\n) whereas in linux it is LF (\n). In my case, this happened due to working on Windows and uploading to Unix server for execution.

  • 1
    Tip: In VSCode in the bottom right corner you can change the line terminator frin "CRLF" to "LF".
    – Avatar
    Mar 24, 2020 at 15:45
  • 1
    Thank you. You are a life saver man. I don't know how is anyone supposed to pick that up from this error message. I have been struggling for days. Then I opened up VS code as you suggested, opened the run.sh file and changed the line endings to LF instead of CRLF. Then I reran the dotnet build and the docker build and the docker run and everything worked, finally!!!!! Thank you. I think in my case I was shielded from this problem when deploying to the external environments because git changes the line endings to LF when we commit, and then back to CRLF when we check out to windows. Sep 29, 2022 at 14:35

Google navigated me to this page. My issue was distantly related to the title of this thread, so I am posting it here for the future visitors like me:

It is one of the weirdest issues:

$ ls -lh
ls: cannot access .~dataprep.ipynb: No such file or directory
-????????? ? ?      ?           ?            ? .~dataprep.ipynb
-rw------- 1 tgowda mygroup 475K Jun 12 15:59 dataprep.ipynb

I see that the file .~dataprep.ipynb is right there with some weird ?? permissions. I just wanted to get rid of that messed up file. rm command could not remove it. mv command couldn't move it.

And then...

$ python
>>> from pathlib import Path
>>> list(Path('.').glob("*.ipynb"))
[PosixPath('.~dataprep.ipynb'), PosixPath('dataprep.ipynb')]
>>> p = list(Path('.').glob("*.ipynb"))[0]
>>> p
>>> p.unlink()
>>> list(Path('.').glob("*.ipynb"))

And that's how I was able to defeat it.


As posted in https://askubuntu.com/a/1035037/676490

sudo apt-get install lsb

solved the problem


None of the above answers worked for me because there was a miss-resolving for the interpreter.

I have written a detailed answer here, explaining how to fix this issue.

Thanks to this man who shared his experience with others solution here. thanks to him i was able to solve this problem.

To summarize, as @steeldriver though, there was an interpreter problem. the linker is giving to my program [/lib/ld64.so.1] as ELF interpreter but this path doesnt exist at all and i checked it by:

> ls /lib/ld64.so.1
ls: cannot access '/lib/ld64.so.1': No such file or directory

After that, i checked the interpreters path's on my ubuntu installation by:

> ls /lib64/ld-*
/lib64/ld-linux-x86-64.so.2  /lib64/ld-lsb-x86-64.so.2  /lib64/ld-lsb-x86-64.so.3

so the solution is to create a link of one of this interpreters to the inexistant interpreter path by:

sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib/ld64.so.1

Now we re-check the inexistent interpreter one more time to see if its still inexisting or not:

> ls /lib/ld64.so.1

Now this command has returned /lib/ld64.so.1 instead of "inexistant file". so the problem was solved and i could run ./main successfully

So, in a summary, you have to create a link of one of this interpreters to the inexistant interpreter path by running the following command in a terminal (Ctrl + Alt + T) :

sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib/ld64.so.1
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review
    – Error404
    Jan 29, 2022 at 9:00
  • done, i hope that you remove that delete vote Jan 29, 2022 at 23:49
  • Thanks for editing your answer, I have further edited it to improve the formatting and grammar. Don't worry about the delete vote, it would be automatically retracted soon!
    – Error404
    Jan 30, 2022 at 6:38

You must log in to answer this question.

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