Executable file isn't "really there" after rsync [duplicate]

Question

This question already has answers here:

Getting "Not found" message when running a 32-bit binary on a 64-bit system (2 answers)

Closed 9 years ago.

I am issuing the following rsync command (obfuscating the exact path & host), which should copy two binaries:

rsync -e "ssh -p 443" -a --info=progress2 -z user@remote:/srv/cgi-bin/ .
user@remotes's password: 
 5,970,149 100% 6.78MB/s 0:00:00 (xfr#2, to-chk=0/3)

From every standpoint I can tell, the command completed successfully.

root@rapunzel:/s/h/p/cgi-bin # >>> ll
total 5.7M
-rwxrwxr-x 1 marcus marcus 3.9M Sep 10 2014 german-numbers
-rwxrwxr-x 1 marcus marcus 1.9M Sep 10 2014 german-numbers-cgi

But when I attempt to run any of the binaries, I get the following error

root@rapunzel:/s/h/p/cgi-bin # >>> ./german-numbers
zsh: no such file or directory: ./german-numbers

So it seems that the binary is not "quite there", but on the other hand I can clearly open and read it:

root@rapunzel:/s/h/p/cgi-bin # >>> head -n1 ./german-numbers
ELF04��'4('444444ドル�=%�=%@%����t��I%������HHHDDP�tdT;%T�T�llQ�td/lib/ld-linux.so.2GNUGNU,B�]2�h$���ɢҒ�S'��� @�P
 ����ݣkĉ����|(�CE���K��8��]���?�������g���FcH▒3
 �_��,�%}�??��>fM7�sn�������F����A{S3a��������,b��)�P▒h�wza�S~�y��*-��y�L
 �����m���<�lp�6����W$%xZ�G��X{��V���� �!� �!�t����@��ԅ����I��ԅ��� ��Ș
 ��librt.so.1__gmon_start___Jv_RegisterClasseslibutil.so.1libdl.so.2libgmp.so.3__gmpz_tdiv_qr__gmpz_and__gmpz_tdiv_q__gmpz_tdiv_r__gmpz_fdiv_qr__gmpn_gcd_1__gmpz_fdiv_q__gmpz_fdiv_r__gmpz_ior__gmpz_mul_2exp__gmp_set_memory_functions_fini__gmpz_sub__gmpz_xor__gmpz_com__gmpz_gcd__gmpz_fdiv_q_2exp__gmpz_init__gmpz_mul__gmpz_divexact__gmpn_cmp__gmpz_addclock_gettimetimer_deletetimer_settimetimer_createdlopendlerrordlsymlibm.so.6modfldexplibc.so.6_IO_stdin_usedepoll_createfflushstrcpysprintfsetlocalefopenstrncmpftruncatestrrchrregexecpipeftruncate64mmap64siginterruptepoll_waitftellstrncpyforksigprocmaskregfreeunlinkpthread_mutex_lockselectmkdirreallocabortgetpidkillstrdupmkstempstrtodstrtolisattysetmntentmmapctime_rfeoffgetscallocstrlensigemptysetmemset__errno_locationtcsetattrfseekgetpagesizeeventfddup2pause__fxstat64sigaddsetpthread_mutex_unlockstdoutfputcgetrusagefputsregerrormemcpyfclosemprotectmallocraisegetgid__lxstat64nl_langinfohasmntopt__xstat64getenv__ctype_b_locregcompstderrsigdelsetmunmapgetuidgetegid__sysv_signalpthread_mutex_initfwritefreadgettimeofdayiconv_closesigactionepoll_ctlstatfsgeteuidlseek64strchrendmntentutimegetlineiconviconv_opentcgetattrbsearchfcntlgetmntent_rmemmovefopen64access_IO_getcstrcmpstrerror__libc_start_mainvfprintfsysconf__environ__cxa_atexit_edata__bss_start_endGLIBC_2.1GLIBC_2.0GLIBC_2.2GLIBC_2.3GLIBC_2.7GLIBC_2.3.4GLIBC_2.3.2GLIBC_2.1.3

I am out of ideas why zsh (and for the record: bash aswell) wont find that file, does anybody have an idea?

• Chris Davies: Output of file german-numbers and uname -a will show details including the architecture. Chances are you've copied a 32bit file to a 64bit system or v.v. Or Intel to ARM, etc.

Answer 1

You are trying to run a 32-bit executable in a 64 bit system. Do do so you have to install the 32 bit libraries, in short, you have to make your system multilib.

or try to recompile by sending the sources as well through rsync.

Answer 2

Output of file german-numbers and uname -a will show details including the architecture.

The chances are that you've copied

1. A 32bit file to a 64bit system or v.v
2. An Intel to ARM or v.v
3. You're missing one or more dynamically linked libraries referenced by the executable. Use ldd german-numbers to see the list of libraries required