Fix ‘Cannot Open Shared Object File: No Such File’ Error

error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory is what just landed in your terminal, and it means the binary you’re trying to run was linked against a library that isn’t sitting where the dynamic linker expects it. Usually it’s one of three things: the package got removed in a distro upgrade, you’re running a binary built for a different OS version than the one you’re on, or ldconfig hasn’t been told about a library you just installed. None of these require a reinstall or a rebuild from source. Grab the exact library name from your error, and you’ll have this running again in about two minutes.

ldd /path/to/your/binary

What This Error Means and When It Hits You

This is a runtime linker error, not a compiler error. Your code compiled fine at some point, got linked against a shared library, and now the dynamic linker (ld.so) can’t find that library on disk when the binary actually tries to run. The .so file it wants either got deleted, moved, renamed during an upgrade, or was never installed on this machine in the first place.

You’ll hit this in a handful of predictable spots. Running a compiled binary you downloaded or built elsewhere is the most common one — think a Go binary that shells out to a C library, or a Python package with a native extension like psycopg2 or numpy. Starting a systemd service after a distro upgrade is another frequent trigger, especially for anything touching OpenSSL, since major version bumps (1.1 to 3.x) rename the .so file entirely. You’ll also see it when executing scripts that call into native dependencies — a Node.js app using node-gyp modules, or a PHP extension compiled against an old libcurl.

The key thing to understand: this has nothing to do with your source code being wrong. The binary exists, it’s executable, and it starts loading — then the linker walks its list of required libraries, fails to resolve one, and bails before your program’s first line of logic even runs.

Missing Library in Standard Search Paths (Most Common Fix)

This is the cause about 80% of the time. The linker checks a fixed set of directories — /lib, /usr/lib, /usr/local/lib, and whatever’s listed in /etc/ld.so.conf.d/ — plus anything in LD_LIBRARY_PATH. If your .so file lives somewhere else, or under a different filename, the binary won’t start. Applies the same way on Ubuntu 22.04/24.04, Debian 12, and most RHEL-based distros.

Use ldd to Identify the Missing Library

ldd /usr/local/bin/myapp

This lists every shared library the binary needs and where the linker resolved it from. A working dependency looks like libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f...). A broken one looks like this:

libssl.so.1.1 => not found

Anything with not found is your problem. Note the exact filename — including the version suffix — because that’s what you search for next. Don’t guess at a substitute; libssl.so.3 is not a drop-in replacement for libssl.so.1.1.

Locate the .so File and Add It to the Search Path

find / -name 'libssl.so.1.1*' 2>/dev/null

This searches the whole filesystem and suppresses permission-denied noise. If it exists, you’ll get a path like /opt/openssl-1.1/lib/libssl.so.1.1. If nothing comes back, the library was never installed — skip to the section on installing the runtime package.

Once you have a path, test the fix temporarily first:

export LD_LIBRARY_PATH=/opt/openssl-1.1/lib:$LD_LIBRARY_PATH
myapp

This tells the linker to check that directory before the default paths, for the current shell session only. If the app starts, you’ve confirmed the fix — now make it stick without relying on environment variables in every terminal.

ldconfig -p | grep libssl

This dumps the linker’s cache of known libraries. If your library isn’t listed here, LD_LIBRARY_PATH is masking the real gap, and any process that doesn’t inherit that variable (cron jobs, systemd services) will still fail.

Make the Fix Permanent with ldconfig

echo "/opt/openssl-1.1/lib" | sudo tee /etc/ld.so.conf.d/custom-openssl.conf
sudo ldconfig -v | grep libssl

The first command registers the directory as a permanent search path. The second rebuilds the linker cache and confirms your library is now indexed — you’ll see it listed among the hundreds of other .so files scanned, with no not found lines for it anywhere in the output. Any process on the system can now find it, no exported variable required.

Library Installed for Wrong Architecture (32-bit vs 64-bit Mismatch)

If the library file exists and ldconfig or LD_LIBRARY_PATH still can’t make it stick, check whether it’s even the right architecture. This causes maybe 15-20% of these errors, usually on servers that mix distro packages with manually compiled software or legacy 32-bit binaries.

Verify Architecture Mismatch with file Command

file /usr/bin/myapp

Expect something like ELF 64-bit LSB executable, x86-64, version 1 (SYSV). Now check the library it’s looking for:

file /usr/lib/x86_64-linux-gnu/libssl.so.1.1

If that comes back ELF 32-bit LSB shared object, Intel 80386, you’ve found the problem. A 64-bit binary cannot load a 32-bit .so file, full stop — no environment variable or symlink fixes an architecture mismatch. The linker error message won’t say “wrong architecture,” it just says cannot open shared object file, which is why people chase this for an hour before running file.

Install the Correct Library Version

On Debian/Ubuntu (20.04/22.04/24.04), check what’s installed and pull the matching arch:

dpkg -l | grep libssl
sudo apt install libssl1.1:amd64

The :amd64 suffix forces the 64-bit build even if a 32-bit version is already registered. If you actually need 32-bit support (old game servers, Wine, some proprietary tools), enable multilib first:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libssl1.1:i386

On RHEL/CentOS/Rocky/Alma (8/9), the package naming uses .x86_64 or .i686 suffixes instead:

rpm -qa | grep libssl
sudo yum install openssl-libs.x86_64
sudo yum install glibc-devel.i686

Confirm the fix with file again on the newly installed path — the architecture string should now match your binary exactly.

Library Version Mismatch or Incompatible Symbols

Sometimes the file is right there, right architecture, and the loader still won’t touch it — because the binary was compiled against a newer library than what’s installed. This shows up about 15% of the time, usually after a distro upgrade lagged behind an app update, or you copied a binary from a newer system onto an older one.

Check Library Symbols and glibc Compatibility

Start by checking what glibc version your system actually has:

ldd /lib64/libc.so.6

This prints something like ldd (GNU libc) 2.31. If your binary needs symbols from 2.34 or later, it’ll fail loading anything linked against them, even though the file exists on disk. You’ll often see the real error buried differently — instead of “no such file,” it’s /lib64/libc.so.6: version 'GLIBC_2.29' not found (required by ./myapp). That’s a version mismatch, not a missing-file problem, so don’t waste time re-checking LD_LIBRARY_PATH.

Dig into a specific library’s exported symbols with:

nm -D /usr/lib/x86_64-linux-gnu/libcrypto.so.3 | grep EVP_PKEY_new

If the symbol is missing, that .so is too old for whatever called it. objdump -T /path/to/libname.so gives the same export table with version tags (like libcrypto.so.3) if nm isn’t installed.

Rebuild or Upgrade the Library

On Debian/Ubuntu, pull a newer package from backports rather than hand-patching glibc:

sudo apt install -t bookworm-backports libssl3

This grabs a version built against current glibc without a full OS upgrade. On RHEL-based systems, check available module streams:

sudo dnf module list openssl

Do not manually replace /lib64/libc.so.6 — overwriting system glibc on a running box can break every dynamically linked binary, including bash and ls, leaving you unable to log back in. If you truly need an incompatible binary running, use a container (Docker with a matching base image) instead of touching host glibc.

Corrupted or Incomplete Library Installation

Sometimes the loader isn’t lying about the file being missing — it’s technically there, just zero bytes or half-written from a package install that got killed mid-write (power loss, OOM killer, apt interrupted with Ctrl+C). The dynamic linker can’t map a truncated file, so it reports it the same as “no such file.”

Check the size first:

ls -lh /usr/lib/x86_64-linux-gnu/libssl.so.3

A healthy OpenSSL 3.x shared object runs 600KB–800KB depending on distro build flags. If you see 0 or a few hundred bytes, it’s broken.

Confirm with file:

file /usr/lib/x86_64-linux-gnu/libssl.so.3

A good library reports something like ELF 64-bit LSB shared object, x86-64, dynamically linked. A corrupted one reports data or empty — no ELF header at all.

Reinstall the package cleanly. On Debian/Ubuntu:

sudo apt install --reinstall libssl3

On RHEL/CentOS/Rocky/Alma:

sudo yum reinstall openssl-libs

Re-run file afterward — you should get the ELF line back, and the app should launch.

Verify the Fix Worked

Don’t just trust that the reinstall worked — check it. Re-run ldd against the binary that was throwing the error:

ldd /usr/bin/your-binary

Every line should show a path like libssl.so.3 => /usr/lib/x86_64-linux-gnu/libssl.so.3 (0x00007f8a2c000000) or say statically linked. If any line still reads => not found, the loader hasn’t found what it needs and you’ve got another library to chase down.

Next, run the binary directly instead of trusting a wrapper script:

your-binary --version

It should print a version string, not error while loading shared libraries. If it’s a background service, check systemctl instead of guessing:

systemctl status your-service

Look for Active: active (running) in green, with no restart-loop timestamps stacking up. If it says failed, run journalctl -u your-service -n 50 and confirm the shared object error is actually gone, not just buried under a newer crash.

Prevent This Error in the Future

Manual installs are the number one cause of this error six months from now. Use your distro’s package manager whenever a library is available there — apt, dnf, or yum track dependencies and update paths correctly. Reserve manual builds for libraries genuinely missing from repos.

If you must install a library to a custom path, document it in a dedicated file under /etc/ld.so.conf.d/ instead of editing /etc/ld.so.conf directly:

echo "/opt/mylib/lib" | sudo tee /etc/ld.so.conf.d/mylib.conf
sudo ldconfig

This gives the next engineer — or you, in a year — one obvious place to look.

Before shipping any compiled binary, run ldd against it on the target OS, not your dev machine:

ldd ./your-binary | grep "not found"

Empty output means every dependency resolves. Anything printed here is a dependency you’re about to ship broken.

In containers, pin library versions explicitly in your Dockerfile rather than trusting latest, and use multi-stage builds so your runtime image only contains what the binary actually links against — not the full build toolchain. A build stage with gcc and dev headers, followed by a slim runtime stage that installs just libssl3 or equivalent, avoids most version drift between build and prod.

Frequently Asked Questions

Related Reads

• Disk Full But df Shows Space: Fix Inode Exhaustion

  Disk full error but df shows free space? Your inodes are exhausted. Find the culprit and fix it in 5 minutes with these …

• How to Reset SSH Connection: 5-Minute Fixes

  SSH connection frozen or hanging? Copy-paste fixes ordered by likelihood. Covers hung sessions, timeout errors, and stal…

• Fix apt broken install: 5 quick solutions

  apt broken install won’t fix? Try these 5 solutions ordered by likelihood. Copy/paste commands, exact error fixes, all L…