Description of problem: file command is unable to recognize some /usr/bin/ binaries as executables - reports "shared object". Version-Release number of selected component (if applicable): file-5.36-2.fc30.x86_64 How reproducible: always Steps to Reproduce: $ find /usr/bin -xdev -type f -print0 | xargs -0 file | grep 'LSB shared object' | awk -F: '{print $1}' Actual results: /usr/bin/smbcontrol /usr/bin/smbtree /usr/bin/rpcclient /usr/bin/sharesec /usr/bin/smbclient /usr/bin/testparm /usr/bin/smbcacls /usr/bin/samba-regedit /usr/bin/dbwrap_tool /usr/bin/profiles /usr/bin/smbget /usr/bin/pdbedit /usr/bin/regdiff /usr/bin/nmblookup /usr/bin/regpatch /usr/bin/regshell /usr/bin/WebKitWebDriver /usr/bin/cifsdd /usr/bin/smbcquotas /usr/bin/smbpasswd /usr/bin/oLschema2ldif /usr/bin/smbstatus /usr/bin/regtree /usr/bin/smbspool /usr/bin/dumpmscat /usr/bin/net /usr/bin/mvxattr Expected results: no output Additional info: Same problem observed many releases ago, for example RHEL6, RHEL7, F28, F29 also affected. For example F28/RHEL8: $ file /usr/bin/zipsplit /usr/bin/zipsplit: ELF 64-bit LSB executable, ... $ file /usr/bin/file /usr/bin/file: ELF 64-bit LSB shared object, ....
This is a known issue: shared libraries and dynamically-linked executables are difficult to distinguish from each other based on ELF header. See also: bug #1570246 bug #1581343 bug #1296868
According to the output of `readelf -h`, the mentioned files are shared objects. This is not a bug per se.