No such file or directory linux как исправить

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.

answered Oct 16, 2010 at 14:25

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.

answered Jan 27, 2014 at 20:24

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 (rn instead of n) that the shebang line (#!/usr/bin/env python) would trip over. A simple dos2unix myfile.py fixed it.

answered Feb 23, 2015 at 15:50

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

answered May 15, 2020 at 15:37

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.

answered Jul 11, 2019 at 21:52

likeGreenlikeGreen

1,0071 gold badge19 silver badges38 bronze badges

icc97icc97

11k8 gold badges72 silver badges88 bronze badges

SoumyaanshSoumyaansh

8,5567 gold badges44 silver badges44 bronze badges

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.

answered Oct 12, 2014 at 21:44

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 (rn) 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.

answered Jan 24, 2020 at 2:54

Pasi SavolainenPasi Savolainen

2,4401 gold badge22 silver badges35 bronze badges

answered Sep 22, 2019 at 12:04

PieterPieter

1,88217 silver badges17 bronze badges

keithphwkeithphw

3801 gold badge4 silver badges14 bronze badges

NavinNavin

3,6262 gold badges28 silver badges51 bronze badges

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

answered Nov 21, 2021 at 19:10

Badr BBadr B

9001 gold badge8 silver badges14 bronze badges

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 rn 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

answered Mar 30 at 13:38

Daniel BraunDaniel Braun

2,35326 silver badges25 bronze badges

FrancescoFrancesco

2,8812 gold badges14 silver badges12 bronze badges

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 . 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 (plus any other necessary library).

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

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.

answered May 11, 2018 at 18:54

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

answered Jun 8, 2016 at 20:57

answered May 9, 2012 at 19:12

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 (rn) whereas in linux it is LF (n). In my case, this happened due to working on Windows and uploading to Unix server for execution.

answered Jan 24, 2020 at 2:55

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

answered Jan 28, 2022 at 21:06

asked Oct 9, 2011 at 2:52

answered Oct 9, 2011 at 9:39

Android SDK requires 32-bit libraries. You probably are on 64-bit and need the 32-bit libs. Here are the troubleshooting directions from developer.android.com

For Ubuntu 13.10 (Saucy Salamander) and above, install the libncurses5:i386, libstdc++6:i386, and zlib1g:i386 packages using apt-get:

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libncurses5:i386 libstdc++6:i386 zlib1g:i386

For earlier versions of Ubuntu, install the ia32-libs package using apt-get:

apt-get install ia32-libs

sudo apt-get install --reinstall libc6-i386

is also need for me.

On a fresh Xubuntu 13.10 x64 install I got adb to run with:

sudo apt-get install --reinstall libc6-i386
sudo apt-get install libstdc++6:i386

And also zlib1g:i386 to make aapt work.

and if you still miss something use:

lld adb

answered Oct 21, 2013 at 1:49

Justin BuserJustin Buser

1,23711 silver badges14 bronze badges

Ubunto seems to have some issues with LSB compatibility, so try this if you are on Ubunto

apt-get install lsb

Note that ldd will sort of show that all the libraries are there, but they are not.

usmp-vm-lamp01$ ldd lmgrd
 linux-vdso.so.1 =>  (0x00007fffb33fe000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f10b0a48000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10b074c000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f10b0535000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10b0175000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f10aff71000)
 /lib64/ld-lsb-x86-64.so.3 => /lib64/ld-linux-x86-64.so.2 (0x00007f10b0c67000)
usmp-vm-lamp01$ locate libpthread.so.0
/lib/x86_64-linux-gnu/libpthread.so.0
usmp-vm-lamp01$ locate libm.so.6
/lib/x86_64-linux-gnu/libm.so.6
usmp-vm-lamp01$ locate /lib64/ld-lsb-x86-64.so.3
usmp-vm-lamp01$

answered Jun 9, 2014 at 21:26