Fix: cannot open shared object file: No such file or directory

The error error while loading shared libraries: libssl.so.1.1: cannot open shared object file means the dynamic loader could not find a shared library a binary depends on, so the program never starts. It is common in slim and Alpine containers that omit libraries, and right after an OS upgrade that replaces a major library version. The binary is asking for one specific file by name, and it is not where the loader looks.

error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

What this error means

When a dynamically linked program starts, the loader (ld.so) resolves every shared library the binary was compiled against, matching each by its soname (like libssl.so.1.1). It searches a fixed set of locations: paths baked into the binary’s RPATH, directories in LD_LIBRARY_PATH, and the system cache built from /etc/ld.so.conf and /etc/ld.so.conf.d. If the exact file is not found in any of them, the loader aborts with “cannot open shared object file”. The version matters: libssl.so.1.1 and libssl.so.3 are different files, and a binary built for 1.1 will not accept 3. On Alpine the twist is deeper, because the whole C library is musl rather than glibc, so a glibc binary cannot load its libraries at all.

Common causes

• A slim or minimal base image (debian-slim, alpine) that never installed the library the binary needs.
• An OS or base image upgrade that bumped the library’s major version, leaving the old soname absent.
• A glibc compiled binary running on Alpine, which uses musl libc.
• A library installed in a nonstandard directory that was never added to the loader cache.
• A statically expected dependency shipped by the app but placed where ld.so does not look.

How to fix it

STABILIZE first. If a deploy took production down, roll back to the previous image or binary that started cleanly while you fix the dependency.

1. DIAGNOSE exactly which libraries are missing. ldd lists every dependency and marks the ones it cannot resolve as “not found”.

ldd /path/to/your-binary

2. Find out which package provides the missing soname on your distribution so you install the right thing. On Debian or Ubuntu based systems:

apt-get update && apt-cache search libssl
dpkg -S libssl.so.1.1 2>/dev/null || true

3. FIX by installing the package that provides the library. On Debian or Ubuntu, libssl1.1 provides libssl.so.1.1:

apt-get update && apt-get install -y libssl1.1

4. If the library lives in a nonstandard directory, register that directory with the loader and rebuild the cache so every process can find it:

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

5. If you are on Alpine and the binary is a glibc build, do not try to copy libraries in. Switch the base image to a glibc distribution:

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y libssl3 ca-certificates \
    && rm -rf /var/lib/apt/lists/*

6. If the library truly only exists in a nonstandard path and you cannot change the loader config, LD_LIBRARY_PATH unblocks you as a stopgap:

LD_LIBRARY_PATH=/opt/mylib /path/to/your-binary

How to prevent it

• Pin base images and rebuild binaries against the C library and library versions in that image, so a binary and its runtime always match.
• Install runtime library dependencies explicitly in your Dockerfile rather than relying on what a slim image happens to include.
• Choose musl builds for Alpine and glibc builds for debian based images; never mix a glibc binary with a musl runtime.
• Run ldd on your binary in CI against the target image to catch a missing dependency before it reaches production.
• When upgrading an OS or base image, check for major library version bumps (libssl.so.1.1 to libssl.so.3, for example) and update dependencies together.

When to call a senior engineer

Call for help when a binary works in one environment and fails in another with no obvious difference, when an upgrade broke a library version you cannot easily rebuild against, or when a musl and glibc mismatch has production down and the fastest safe path is unclear. Erzon engineers can trace every dependency a binary needs, get the right libraries onto the loader path, and settle the base image and build so this stops happening on the next deploy.