/usr is one of the largest directories on any Linux system by file count, and one of the most misunderstood by name. Despite looking like it should mean “user,” it has nothing to do with personal files: that role belongs to /home. /usr is where the bulk of installed software actually lives.

What /usr actually holds

ls /usr
# bin  games  include  lib  lib64  local  sbin  share  src

ls /usr/bin | wc -l
# often 1000-3000+ entries on a typical system

The name is a historical relic. In early Unix, /usr genuinely did hold user home directories, before that responsibility moved to the dedicated /home directory. /usr was repurposed afterward to hold secondary system files and installed programs, and that repurposed meaning is the one that stuck through every modern distribution.

The internal layout of /usr

/usr/bin/       # almost all installed command-line programs
/usr/sbin/      # administrative binaries (traditionally requiring root)
/usr/lib/       # shared libraries used by programs in /usr/bin
/usr/include/   # C/C++ header files for compiling software
/usr/share/     # architecture-independent data: docs, icons, man pages, locale data
/usr/local/     # software installed manually, outside the package manager
/usr/src/       # kernel source code and headers, when installed

This mirrors the structure of / itself in miniature, which is intentional. /usr was originally designed so an organization could keep it on a separate, shared network filesystem mounted read-only by many client machines, each with its own small local / for host-specific files. That specific use case has mostly disappeared, but the parallel directory structure remains.

/bin vs /usr/bin: the usr merge

This is the single most common point of confusion around /usr. Historically:

/bin/       # essential binaries needed to boot, before /usr was mounted
/usr/bin/   # everything else

The reasoning made sense decades ago when /usr might be a separate, sometimes slower or network-attached filesystem that was not guaranteed to be available in the earliest stages of boot. A minimal set of essential tools (ls, cp, mv, a shell) needed to exist somewhere that was always available, hence /bin.

On virtually every mainstream distribution today, this distinction has been eliminated through what is commonly called the “usr merge”:

ls -la /bin
# lrwxrwxrwx 1 root root 7 Mar  1 09:15 /bin -> usr/bin

ls -la /sbin
# lrwxrwxrwx 1 root root 8 Mar  1 09:15 /sbin -> usr/sbin

/bin and /sbin are now symbolic links pointing into /usr/bin and /usr/sbin respectively. A command like ls genuinely lives in only one place, /usr/bin/ls, and /bin/ls simply follows the symlink to reach it. This simplification removed a whole category of packaging ambiguity, where maintainers previously had to decide, somewhat arbitrarily, which of the two directories a given binary belonged in.

# Confirm a binary's real location
readlink -f /bin/ls
# /usr/bin/ls

which ls
type ls

/usr vs /opt

Both directories hold installed software that is not part of the base operating system, but they organize it differently:

# /usr: package-managed software, integrated into the shared layout
/usr/bin/htop        # binary
/usr/share/doc/htop/ # documentation
/usr/share/man/man1/htop.1.gz  # man page

# /opt: self-contained third-party software, all in one place
/opt/google/chrome/chrome
/opt/google/chrome/chrome-sandbox
/opt/google/chrome/resources/

Software installed through apt, dnf, pacman, or the equivalent distribution package manager scatters its files across the shared /usr hierarchy: the binary in /usr/bin, libraries in /usr/lib, documentation in /usr/share/doc. Third-party software distributed as a single self-contained bundle, common for commercial applications, often installs itself entirely under one directory in /opt instead, to avoid depending on or conflicting with the distribution’s own library versions.

/usr/local: the third option

/usr/local/bin/    # manually compiled or installed binaries
/usr/local/lib/    # their libraries
/usr/local/share/  # their shared data

/usr/local exists specifically for software installed outside the package manager, such as something built from source with ./configure && make && sudo make install. Keeping it separate from /usr proper means the package manager never has to reason about files it did not install, and a distribution upgrade or reinstall never risks silently wiping out software an administrator compiled by hand.

# A classic manual install pattern
./configure --prefix=/usr/local
make
sudo make install
# binary lands at /usr/local/bin/programname

Managing what is in /usr

Because /usr is managed by the package manager, the correct way to add or remove software here is always through the package manager itself, never by manually copying or deleting files:

# Install and remove cleanly through the package manager
sudo apt install htop
sudo apt remove htop

sudo dnf install htop
sudo dnf remove htop

# Verify which package owns a specific file in /usr
dpkg -S /usr/bin/htop     # Debian/Ubuntu
rpm -qf /usr/bin/htop      # Fedora/RHEL

# List every file a package installed
dpkg -L htop
rpm -ql htop

Manually deleting a file from /usr/bin with rm leaves the package manager’s internal database still believing the file exists, which can produce confusing errors the next time that package is updated or removed. Uninstalling through the proper package command avoids this entirely, since it removes every file the package originally placed and updates the tracking database at the same time.

Frequently Asked Questions

What is the /usr directory used for?

Despite the name looking like an abbreviation of “user,” /usr does not hold personal user files; that is what /home is for. /usr holds the majority of installed software on a Linux system: binaries, libraries, documentation, and shared data that the package manager installs. It is meant to be read-only during normal operation and, in theory, shareable across multiple machines on a network.

What is the difference between /bin and /usr/bin?

Historically, /bin held the small set of essential binaries needed to boot the system before /usr was mounted, back when /usr sometimes lived on a separate, slower, or network-mounted disk. /usr/bin held everything else. On virtually every modern Linux distribution, including Ubuntu, Debian, Fedora, and Arch, this distinction has been eliminated: /bin is now a symbolic link to /usr/bin, so both paths point to the exact same files. This is commonly called the usr merge.

Why did the usr merge happen?

The historical reason for separating /bin and /usr/bin, having /usr on its own disk that might not be available at early boot, stopped applying to virtually all modern systems, since /usr is now almost always on the same disk and mounted at boot. Maintaining two separate binary directories added complexity without benefit: package maintainers had to decide which directory a binary belonged in, and tools had to search both. Merging them into one location, with /bin as a symlink to /usr/bin, simplified packaging and eliminated an entire category of “why is this binary in the wrong directory” bugs.

What is the difference between /usr and /opt?

/usr holds software installed and managed by the distribution’s package manager, integrated into the standard directory layout (its binaries in /usr/bin, its libraries in /usr/lib, and so on). /opt holds self-contained, typically third-party software that keeps all its own files, including its own binaries and libraries, inside a single dedicated subdirectory rather than spreading them across the shared /usr hierarchy. Software installed via apt, dnf, or pacman generally lands in /usr; software you download and install manually as a standalone package often lands in /opt.

What is /usr/local for?

/usr/local is where software installed manually, outside the distribution’s package manager, is meant to go, following the same internal layout as /usr (its own bin, lib, share subdirectories). This keeps manually compiled or installed software separate from what the package manager tracks, so a package manager operation is never at risk of overwriting something an administrator installed by hand, and vice versa. Running make install from a source tarball typically defaults to installing under /usr/local.

Can I safely delete files from /usr?

Not directly with rm. Files under /usr are owned and tracked by the package manager, and manually deleting them can leave the package database in an inconsistent state, causing confusing errors on future updates. The correct way to remove software from /usr is to uninstall the package properly, with apt remove, dnf remove, or pacman -R, which cleans up every file the package originally installed and updates the package database accordingly.