"No such file or directory" but it exists

Question

I simply want to run an executable from the command line, ./arm-mingw32ce-g++, but then I get the error message,

bash: ./arm-mingw32ce-g++: No such file or directory

I'm running Ubuntu Linux 10.10. ls -l lists

-rwxr-xr-x 1 root root  433308 2010-10-16 21:32 arm-mingw32ce-g++

Using sudo (sudo ./arm-mingw32ce-g++) gives

sudo: unable to execute ./arm-mingw32ce-g++: No such file or directory

I have no idea why the OS can't even see the file when it's there. Any thoughts?

Mcgean

Answer 1

This error can mean that ./arm-mingw32ce-g++ doesn't exist (but it does), or that it exists and is a dynamically linked executable recognized by the kernel but whose dynamic loader is not available. You can see what dynamic loader is required by running ldd /arm-mingw32ce-g++; anything marked not found is the dynamic loader or a library that you need to install.

If you're trying to run a 32-bit binary on an amd64 installation:

• Up to Ubuntu 11.04, install the package ia32-libs.
• On Ubuntu 11.10, install ia32-libs-multiarch.
• Starting with 12.04, install ia32-libs-multiarch, or select a reasonable set of :i386 packages in addition to the :amd64 packages.

Cohort

Awesome, works! By the way, output of ldd was not a dynamic executable (before I installed ia32-libs). – Mcgean

ia32-libs-* is deprecated in Ubuntu 16.04, install lib32ncurses5 and lib32z1 instead. – Sweeting

This is a common issue on Nix or NixOS when trying to run 3rd party binaries; see patchelf. – Torero

@Sweeting helped me. Thanks. I had to install lib32z1 – Wollastonite

ldd might return the misleading not a dynamic executable message. In this case the shared library dependencies can be figured out by less sophisticated tools e.g. with objdump ./arm-mingw32ce-g++ – Cohe

Why does it produce this error message when it's just missing so's? – Gaily

@Gaily You don't get this error message if some shared library is missing. Only if the loader itself is missing. – Martlet

Thanks, though this begets another question; why does it mention the binary rather than the loader? – Gaily

@Gaily unix.stackexchange.com/questions/13391/… – Martlet

@Gilles'SO-stopbeingevil' "the error you get may refer to the loader rather than the file you're executing" is the opposite problem. But "fixing this would be hard because the kernel interface only has room for reporting a numeric error code" answers the question I guess. – Gaily

@Cohe I was gettting an error when using objdump <file> without any parameters, I added -f to get it process the file, like so: objdump -f <file> – Waers

Answer 2

I faced this error when I was trying to build Selenium source on Ubuntu. The simple shell script with correct shebang was not able to run even after I had all pre-requisites covered.

file file-name # helped me in understanding that CRLF ending were present in the file.

I opened the file in Vim and I could see that just because I once edited this file on a Windows machine, it was in DOS format. I converted the file to Unix format with below command:

dos2unix filename # actually helped me and things were fine.

I hope that we should take care whenever we edit files across platforms we should take care for the file formats as well.

Disown

A decade late, but credit where credit is due. In my case using WSL2 on windows with windows directories mounted inside the distro running on WSL. Windows line endings - unix files. – Chastitychasuble

Thanks, @BrentonThomas. I am glad that it helped. I haven't tried WSL on Windows yet. I wish to use it soon. – Disown

Thanks, this was actually my mistake. I built a docker image on windows and copied a shell script to the image that had the wrong line endings. – Accost

Answer 3

This error may also occur if trying to run a script and the shebang is misspelled. Make sure it reads #!/bin/sh, #!/bin/bash, or whichever interpreter you're using.

Monteux

I'm referring to an executable, not a script. Then again, someone else may find this comment useful – Mcgean

True, but I landed on this question for this exact problem, so as you said, maybe someone else will as well. – Stenophagous

In my case, I was trying to run ./my/full/path/myscript instead of ./myscript. – Ambsace

Answer 4

I had the same error message when trying to run a Python script -- this was not @Warpspace's intended use case (see other comments), but this was among the top hits to my search, so maybe somebody will find it useful.

In my case it was the DOS line endings (\r\n instead of \n) that the shebang line (#!/usr/bin/env python) would trip over. A simple dos2unix myfile.py fixed it.

Bucephalus

I've got the same thing while working on symfony project to run ./bin/console . – Lastminute

Answer 5

I found my solution for my Ubuntu 18 here.

sudo dpkg --add-architecture i386

Then:

sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

Hypnotism

Answer 6

As mentioned by others, this is because the loader can't be found, not your executable file. Unfortunately the message is not clear enough.

You can fix it by changing the loader that your executable uses, see my thorough answer in this other question: Multiple glibc libraries on a single host

Basically you have to find which loader it's trying to use:

$ readelf -l arm-mingw32ce-g++ | grep interpreter
  [Requesting program interpreter: /lib/ld-linux.so.2]

Then find the right path for an equivalent loader, and change your executable to use the loader from the path that it really is:

$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 arm-mingw32ce-g++

You will probably need to set the path of the includes too, you will know if you want it or not after you try to run it. See all the details in that other thread.

Jost

In my case on top of the confusing error message ldd also erroneously reported that the loader is found: /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2, but it was actually not true. This can be fixed by ln instead of patchelf: sudo ln /lib64/ld-linux-x86-64.so.2 /lib/ld-linux-x86-64.so.2. – Osteo

patchelf is good if you don't have root access to the machine, and/or if you'll only fix one binary. If you have several binaries with this problem and need to create a system-wide link, then probably the system is inconsistent and it would be better to rethink the strategy.... do some recovery or re-install... – Jost

Answer 7

I got the same error for a simple bash script that wouldn't have 32/64-bit issues. This is possibly because the script you are trying to run has an error in it. This ubuntu forum post indicates that with normal script files you can add sh in front and you might get some debug output from it. e.g.

$ sudo sh arm-mingw32ce-g++

and see if you get any output.

In my case the actual problem was that the file that I was trying to execute was in Windows format rather than Linux.

Developer

Answer 8

I got this error “No such file or directory” but it exists because my file was created in Windows and I tried to run it on Ubuntu and the file contained invalid 15\r where ever a new line was there. I just created a new file truncating unwanted stuff

sleep: invalid time interval ‘15\r’
Try 'sleep --help' for more information.
script.sh: 5: script.sh: /opt/ag/cont: not found
script.sh: 6: script.sh: /opt/ag/cont: not found
root@Ubuntu14:/home/abc12/Desktop# vi script.sh 
root@Ubuntu14:/home/abc12/Desktop# od -c script.sh 
0000000   #   !   /   u   s   r   /   b   i   n   /   e   n   v       b
0000020   a   s   h  \r  \n   w   g   e   t       h   t   t   p   :   /

0000400   :   4   1   2   0   /  \r  \n
0000410
root@Ubuntu14:/home/abc12/Desktop# tr -d \\015 < script.sh > script.sh.fixed
root@Ubuntu14:/home/abc12/Desktop# od -c script.sh.fixed 
0000000   #   !   /   u   s   r   /   b   i   n   /   e   n   v       b
0000020   a   s   h  \n   w   g   e   t       h   t   t   p   :   /   /

0000400   /  \n
0000402
root@Ubuntu14:/home/abc12/Desktop# sh -x script.sh.fixed 

Bergerac

Answer 9

Added here for future reference (for users who might fall into the same case): 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). This can be usually be chosen in text editor.

In my case, this happened due to working on Windows and uploading to Unix server for execution.

Wace

I use docker, linux, but build it from Windows. My script started scriptdir=$(cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd) then cd $scriptdir || exit 1 but the \r in my windows-edited file got appended to the scriptdir value. So the message : no such file or directory was most confusing, since it ended up erasing what it was complaining about. – Cowitch

Answer 10

I had the same problem with a file that I've created on my mac. If I try to run it in a shell with ./filename I got the file not found error message. I think that something was wrong with the file.

what I've done:

open a ssh session to the server
cat filename
copy the output to the clipboard
rm filename
touch filename
vi filename
i for insert mode
paste the content from the clipboard
ESC to end insert mode
:wq!

This worked for me.

Inalienable

take a look at previous answers, you have a problem because of windows style. If you had run dos2unix.exe over your file you would have got the same result :-). – Aalst

Answer 11

Below command worked on 16.4 Ubuntu

This issue comes when your .sh file is corrupt or not formatted as per unix protocols.

dos2unix converts the .sh file to Unix format!

sudo apt-get install dos2unix -y
dos2unix test.sh
sudo chmod u+x test.sh 
sudo ./test.sh

Anitraaniweta

Answer 12

In a .sh script, each line MUST end with a single character - newline (LF or "\n").

Don't make mistakes like me, because my text-editor of choice is Notepad++ in Win. The default line ending in Win is "\r\n" (CR LF), and such ending is not standard for Linux shell scripts.

Sympathizer

Answer 13

I just had this issue in mingw32 bash. I had execuded node/npm from Program Files (x86)\nodejs and then moved them into disabled directory (essentially removing them from path). I also had Program Files\nodejs (ie. 64bit version) in path, but only after the x86 version. After restarting the bash shell, the 64bit version of npm could be found. node worked correctly all the time (checked with node -v that changed when x86 version was moved).

I think bash -r would've worked instead of restarting bash: https://unix.stackexchange.com/a/5610

Fulfil

Answer 14

I had this issue and the reason was EOL in some editors such as Notepad++. You can check it in Edit menu/EOL conversion. Unix(LF) should be selected. I hope it would be useful.

Guiscard

That is unlikely to be the problem in this case,as the command is not executed from a file. – Reviel

Answer 15

Hit this error trying to run terraform/terragrunt (Single go binary).

Using which terragrunt to find where executable was, got strange error when running it in local dir or with full path

bash: ./terragrunt: No such file or directory

Problem was that there was two installations of terragrunt, used brew uninstall terragrunt to remove one fixed it.

After removing the one, which terragrunt showed the new path /usr/bin/terragrunt everything worked fine.

Lumberjack

Answer 16

For those encountering this error when running a java program, it's possible that you're trying to run a 64-bit java program using on a 32-bit linux operating system.

I only realised when I ran ldd on 64-bit java which reported:

ldd /usr/java/jdk1.8.0_05/bin/java

'not a dynamic executable'

Whereas the old 32 bit java reported sensible results:

ldd /usr/java/jdk1.8.0_05/bin/java

Ferryman

Answer 17

This: sed -i -e 's/\r$//' FILE, could potentially fix your problem.

As many answers already have explained, this issue could be caused by line endings being \r\n in Windows and only \n in Linux. A suggested approach was to use dos2unix. As far as I understand this is not standard on most Linux distributions, and in my case I could not install / use it.

Therefore I used the following approach, (mentioned in Bash script – "/bin/bash^M: bad interpreter: No such file or directory"), where you can use the sed command instead.

sed -i -e 's/\r$//' FILE where you replace FILE with the name of your file, e.g. sed -i -e 's/\r$//' myscript.sh

If you for some reason do not have sed installed but do not want to use dos2unix you can use the following to install sed:

sudo apt-get update
sudo apt-get install sed

Adnopoz

If the above does not work this could: sed -i -e 's/^M$//' myscript.sh. Alternatively using vim: :set fileformat=unix – Adnopoz

Answer 18

In my case, it turns out the file was a symlink:

$ cat deluge-gtk.lock
cat: deluge-gtk.lock: No such file or directory
$ file deluge-gtk.lock
deluge-gtk.lock: broken symbolic link to 32309

Misleading errors like this are fairly common on Linux. Related discussion: https://lwn.net/Articles/532771/

Danny

Answer 19

For future readers, I had this issue when trying to launch a Django server using gunicorn. I was using AWS CodeBuild to build the virtual environment and run tests and using CodeDeploy to put the built artifacts onto the production server and launch the new version (all environments were Ubuntu 20.04). I had mistakenly thought that env/bin/... contained actual binaries of native libraries but that was not the case. It was just Python scripts with a shebang of the path to the Python interpreter on the build machine. In my case, the machine installing the packages and actually running the packages was different. To be more specific, all of the files in env/bin had the shebang #!/codebuild/output/src715682316/src/env/bin/python, so of course running env/bin/gunicorn on the production server would fail. The cryptic error message was when Ubuntu would tell me that env/bin/gunicorn didn't exist as opposed to saying /codebuild/output/src715682316/src/env/bin/python didn't exist. I was able to fix this problem by starting gunicorn using python3 env/bin/gunicorn instead of env/bin/gunicorn.

Cleavable

Answer 20

Yet another possible reason: the file is a binary linked dynamically against musl (most likely for alpine)

on debian system you will have to install

apt-get update -y && apt-get install -y musl musl-dev musl-tools

Vyky

Answer 21

not the same problem, but maybe helpful for some people

my script:

#!/bin/sh

calm-cat="$HOME/blabla"
echo $calm-cat

i have blabla in my home directory, but

error message: ./b.sh: line 3: calm-cat=/home/bob/blabla: No such file or directory

it's because shell script variable name can't contain dash (-)

so change it to calm_cat will solve that problem

Castigate