Bash: No such file or directory?

Question

I try to use an executable script (wkhtmltopdf) on a Linux shared webserver (Debian, 64bit). I am pretty sure that I compiled everything correct, but whenever I want to execute the file I get as an response :

> ./wkhtmltopdf -H
-bash: ./wkhtmltopdf: No such file or directory

To be sure that the file is there, here the ls output :

> ls
wkhtmltoimage  wkhtmltopdf

Furthermore I tested the file command on it, which outputs the following :

> file wkhtmltopdf
wkhtmltopdf: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

My question is now :

Why does bash tells me that there is no 'file or directory', when there obviously is one?

My first guess would be that the shared server does not allow to execute binary files? But shouldn't it then be a problem of permissions, with a different bash output?

Edit :

> id 
uid=2725674(p8907906) gid=600(ftpusers) groups=600(ftpusers)

> ls -l wkhtmltopdf
-rwxrwxrwx 1 p8907906 ftpusers 39745960 Jan 20 09:33 wkhtmltopdf

> ls -ld
drwx---r-x 2 p8907906 ftpusers 44 Jan 28 21:02 .

Rimini

If your filesystem is mounted with "noexec" option you get a "Permission denied. – Sizable

What are the permissions? – Hyetography

Add to your question output of: id and ls -l wkhtmltopdf – Sizable

that looks right, what about perms you see on your curr_dir and parent_dir, ie. ls -ld . .. . Good luck. – Rost

Try restarting that instance of bash. – Matthaeus

Thanks for all the input :). I think I really just lack of the interpreter given by @nsilent22 – Rimini

Answer 1

I bet you miss dynamic linker. Just do a

readelf --all ./wkhtmltopdf | grep interpreter

You should get an output like this:

[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

There are high chances that you system lacks the interpreter (/lib64/ld-linux-x86-64.so.2 in the example). In this case bash would yell No such file or directory, just like when the binary itself is missing.

You can try to use a different linker. Sometime you can succeed. Just do a:

/path/to/the/linker /path/to/your/executable

This command:

find /lib* -name ld-linux\*

will help you find the linkers on your system. Or you can do the readelf command on some command that does run. It will show you correct, working linker.

OR, since you are running Debian system, just do a

sudo apt-get install wkhtmltopdf

to install native version of the tool :)

Steffi

The output is exactly as you said. How can I now definetly check if /lib64/ld-linux-x86-64.so.2exists? – Rimini

Issue a ls -l /lib64/ld-linux-x86-64.so.2. Paste it's output here. – Steffi

ls output is: ls: cannot access /lib64/ld-linux-x86-64.so.2: No such file or directory so thx :) – Rimini

Yes for one second I stopped thinking :D – Rimini

I updated my answer how you can "override" the problem, if the binary isn't linked with exotic libraries. – Steffi

Thx for the additional answers. sudo I have no admin rights an therefore cannot use apt-get, different linker I tried this options but with no success: find /lib* -name ld-linux\* outputs: /lib/ld-linux.so.2 and /lib/i686/cmov/ld-linux.so.2 now I tried /lib/ld-linux.so.2 wkhtmltopdf -H with the output wkhtmltopdf: error while loading shared libraries: wkhtmltopdf: cannot open shared object file: No such file or directory, the same happend with the other linker. In general I think I cannot use wkhtmltopdf on this shared server ;) – Rimini

@Knowledge: Are you sure this machine is 64bit? What uname -m outputs? – Steffi

> uname -m outputs : x86_64, so I guess I am running on a 64bit system? – Rimini

@Knowledge: Looks like. So, if you don't have admin-rights you can try to manually download the package (e.g. from here: packages.debian.org/jessie/amd64/wkhtmltopdf/download), and then manually unpack it, and you'll get the binary. But it looks like it depends on lots of other libraries (Qt5 for example), so I think the game is not worth the candle. – Steffi

Well done. I had this problem when trying to run a RHEL executable on Ubuntu. You might mention this as a possible reason in your answer. – Bilingual

Answer 2

In my case

$ readelf --all ./wkhtmltopdf | grep interpreter # readelf: Displays information about ELF files.
      [Requesting program interpreter: /lib/ld-linux.so.2]

On a machine where the executable was working:

$ ls -lah /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 25 Apr 16  2018 /lib/ld-linux.so.2 -> i386-linux-gnu/ld-2.27.so
$ dpkg -S /lib/ld-linux.so.2  # -S, --search filename-search-pattern: Search for a filename from installed packages.
libc6:i386: /lib/ld-linux.so.2

So to fix the problem (reference)

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libc6:i386  # GNU C Library: Shared libraries (from apt show)

Mizzenmast

Answer 3

Missing the linker was my case as well. I could fix it with the help of nsilent22 answer like this:

readelf --all  /usr/local/myprogram | grep interpreter
[Requesting program interpreter: /lib64/ld-lsb-x86-64.so.3]

But that linker did not exist anymore.

The old situation in /lib64 was:

ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
ld-linux-x86-64.so.3 -> ld-linux-x86-64.so.2

So it turned out this was just a symlink to the systems' linker.

Moving over to /lib64 , which itself is a symlink to usr/lib64 and creating a symlink over there did not work. I assume that there are to many symbolic link levels after Debian moved everything into /usr

However creating a 'direct' symlink

ln -s /usr/lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3

did the job; /usr/lib64 now shows:

ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
ld-lsb-x86-64.so.3 -> /usr/lib64/ld-linux-x86-64.so.2

Grenoble

Answer 4

I ran into this issue on my raspberry pi 4 running aarch64 alpine 3.13. Using the answer provided by @vkersten, I was able to determine that I was missing /lib/ld-linux-aarch64.so.1.

I resolved this by installing gcompat with apk add gcompat.

Nebulous