"No such file or directory" but it exists

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

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.

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

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.

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.

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.

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.

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

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/

Give it a try by changing the name of file or folder which is not showing in terminal/command prompt.

step1 : change the name of file or folder. step2 : cd filename/foldername

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.