Linux Common Directories:Know Where Things Live

A service will not start, a deploy filled the disk, or someone asks “where does nginx keep its config?” — and you stare at a tree of names that all look important. Linux is not hiding things; it follows a shared layout called the Filesystem Hierarchy Standard (FHS). Once you know what each top-level directory is for, you stop guessing and start looking in the right place.

This guide is directory literacy, not a tour of every flag. You will explore with safe read-only commands, learn the mental model behind /, /etc, /var, /usr, and friends, and finish with a quick map you can keep nearby.

Warm-up: look at the root without changing anything

Start at / — the root of the tree. Everything else hangs under it, whether it lives on the same disk or on another mount.

ls /

You should see familiar names such as bin, boot, dev, etc, home, lib, opt, proc, root, run, sbin, sys, tmp, usr, and var (exact set varies by distro). Check a few with long listing so ownership and permissions are visible:

ls -ld /etc /var /usr /home /tmp /root

When you want the official map on a machine that ships it, read the hierarchy man page:

man 7 hier

Note: Prefer ls, df, and readlink while you learn. Recursively deleting under / or editing files under /proc and /sys can break a running system. Explore first; change later with intent — and use sudo only when a write truly needs privilege.

Root vs mounts: names are not the same as disks

/ is one tree. That tree can span several filesystems. /home might be a separate partition; /boot often is; a USB stick appears under /media or /mnt. Directory names describe purpose. Mounts decide which disk backs that path.

See what is mounted and how full each filesystem is:

df -h

For space hunts once you know which mount is full, use du and df. For locating a path by name anywhere under a tree, reach for find.

Note: Filling /var or /tmp can freeze services even when /home still has free space. Always check df -h before assuming “the disk” is one bucket.

Binaries: /bin, /sbin, /usr/bin, /usr/sbin

Commands live as files. Historically:

• /bin and /sbin held essential tools needed early in boot (and for recovery).
• /usr/bin and /usr/sbin held the rest of the userland and admin tools.

On modern Debian, Ubuntu, Fedora, and many others, /bin and /sbin are often symlinks into /usr. The names remain for compatibility; the real files live under /usr.

Confirm where a command resolves and whether the top-level dirs are links:

type -a ls
which ls
ls -ld /bin /sbin /usr/bin /usr/sbin
readlink -f "$(which ls)"

Note: If ls -ld /bin shows -> usr/bin, you are on a merged-/usr layout. That is normal. Old docs that say “put rescue tools only in /bin” still apply conceptually; the paths just redirect into /usr.

Boot files: /boot

/boot holds the kernel image, initramfs, and often the bootloader config (GRUB). You rarely edit these by hand; package updates and installers manage them. Look here when a kernel upgrade failed, GRUB needs attention, or /boot itself is a small separate partition that filled up.

ls /boot
df -h /boot

Note: A full /boot is a classic “updates fail” symptom. Check size with df -h /boot before blaming the package manager.

Devices: /dev

/dev is not ordinary storage. It exposes device nodes — disks (sda, nvme0n1), partitions, TTYs, null, random, and more. Programs open these paths to talk to hardware and kernel drivers.

ls /dev | head
ls -l /dev/null /dev/sda 2>/dev/null

Note: Writing to the wrong /dev/sd* path can wipe a disk. Treat block devices as dangerous until you have verified the name with lsblk.

Configuration: /etc

/etc is the system’s configuration home: network settings, service unit overrides, package configs, user databases (passwd, group), and more. When a daemon “won’t take my change,” the file you need is almost always under /etc (or a drop-in directory next to it).

ls /etc | head -n 20
ls /etc/ssh 2>/dev/null
ls /etc/systemd/system 2>/dev/null

Common places you will open:

• /etc/systemd/ — units and drop-ins for services
• /etc/ssh/ — SSH daemon and client config
• /etc/<package>/ — nginx, apache2, postgresql, and friends
• /etc/sudoers and /etc/sudoers.d/ — privileged access (edit with visudo; see sudo and sudoers)

Note: Prefer the package’s documented path and drop-in directories over editing vendored defaults in place when the distro supports overrides. After config edits, restart or reload the matching unit — and confirm with journalctl if it fails.

Home directories: /home and /root

/home/<user> is where each normal user’s files, shell config (.bashrc), SSH keys (.ssh), and projects live. /root is the root user’s home — not the same as /.

ls -ld /home /root
echo "$HOME"

Note: Permissions on homes matter. Other users should not read your private keys. When ownership or modes look wrong, fix them deliberately with chmod, chown, and umask.

Libraries: /lib, /lib64, /usr/lib

Shared libraries (.so files) that programs link against live under /lib, /lib64, and /usr/lib (again often merged under /usr). You seldom browse here day to day, but “library not found” errors and packaging problems point here.

ls -ld /lib /lib64 /usr/lib 2>/dev/null

Optional software: /opt and /usr/local

Both hold software that is not the core OS package set, with different conventions:

• /opt — self-contained third-party or vendor bundles, often one directory per product (/opt/google/chrome, /opt/myapp).
• /usr/local — admin-installed software that should look like the FHS (bin, lib, share under /usr/local), typical for tools you compile or install outside the distro packages.

ls /opt 2>/dev/null
ls /usr/local
ls /usr/local/bin 2>/dev/null

Note: Prefer distro packages when they exist. Use /usr/local for your own builds; use /opt when a vendor ships a whole tree that should stay isolated.

Shared data: /usr and /usr/share

/usr is the bulk of the operating system’s userland: binaries, libraries, documentation, and architecture-independent data. Under it, /usr/share holds man pages, locales, icons, and other shared files that are not machine-specific binaries.

ls /usr
ls /usr/share/man 2>/dev/null | head

Note: Treat /usr as package-managed. Put custom installs under /usr/local or /opt so upgrades do not fight your files.

Variable data: /var

/var is where things grow while the system runs: logs, databases, caches, mail spools, package manager state. When disk fills mysteriously, /var is a prime suspect.

ls /var
df -h /var

Important nested paths:

• /var/log — traditional log files (many hosts also use the systemd journal; see journalctl)
• /var/lib — persistent state for packages and services (databases, docker data on some setups, package manager DBs)
• /var/cache — regenerable caches (safe to clear more often than /var/lib, but still check docs)
• /var/tmp — temporary files meant to survive reboot (unlike /tmp on many systems)
• /var/spool — queues (mail, print, cron)

Peek without flooding the terminal:

ls /var/log | head
ls /var/lib | head
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h

Note: Clearing /var/lib can destroy application data. Prefer trimming /var/log and /var/cache with known tools (journalctl --vacuum-size=…, package clean commands) over blind rm -rf.

Runtime state: /run

/run holds data that only needs to last for the current boot: PID files, runtime sockets, transient service state. It is typically a tmpfs in RAM — empty again after reboot.

ls /run | head
df -h /run

Note: Do not put durable data here. If something must survive reboot, it belongs under /var or /etc, not /run.

Temporary files: /tmp

/tmp is for short-lived scratch files. Many systems clear it on reboot (via tmpfs or a cleanup service). Any user can usually create files here, subject to sticky-bit rules on the directory.

ls -ld /tmp
df -h /tmp

Note: Prefer /tmp for true scratch; use /var/tmp when a temp file should survive a reboot. Never store secrets in world-readable temp dirs longer than needed.

Kernel interfaces: /proc and /sys

These are virtual filesystems. They look like directories but are windows into the kernel and running processes — CPU info, memory, mount tables, device trees, tunables.

ls /proc | head
head -n 5 /proc/cpuinfo
ls /sys | head

Useful examples without changing anything:

cat /proc/meminfo | head
readlink /proc/self/exe

Note: Reading is educational; writing sysctls or device attributes can change live behavior. Prefer documented tools (sysctl, systemctl) over hand-editing numbers under /proc and /sys until you know exactly what you are doing.

Mount points: /mnt, /media, and /srv

• /mnt — classic place for temporary admin mounts (an ISO, an extra disk you attach for maintenance).
• /media — typically removable media mounted by the desktop or automounter (USB sticks, CDs).
• /srv — site-specific data served by this system (optional; some shops put web or FTP trees here instead of under /var).

ls -ld /mnt /media /srv 2>/dev/null

Nested paths worth memorizing

When you already know the top-level purpose, these shortcuts save time:

Look here when…	Path
A service config needs editing	/etc/<service>/ or /etc/systemd/
SSH is misbehaving	/etc/ssh/
Disk grew overnight	/var/log, /var/lib, /var/cache
You installed something outside packages	/usr/local or /opt
You need man pages or shared assets	/usr/share
You need current PID/socket state	/run
You need hardware or process introspection	/proc, /sys

Quick reference

Path	Purpose	Typical use
/	Filesystem root	Starting point of the tree
/bin, /sbin	Essential commands (often → /usr)	Core tools; recovery context
/usr/bin, /usr/sbin	User and admin commands	Day-to-day CLI and daemons
/boot	Kernel and bootloader	Boot failures; small partition full
/dev	Device nodes	Disks, TTYs, special files
/etc	Configuration	Service and system settings
/home	User homes	Projects, dots, personal files
/root	root’s home	Admin’s private files
/lib, /lib64, /usr/lib	Shared libraries	Linking / packaging issues
/opt	Optional vendor trees	Third-party bundles
/usr	Userland OS files	Package-managed software
/usr/local	Local admin installs	Custom builds
/usr/share	Shared read-only data	man pages, docs, assets
/var	Variable growing data	Logs, DBs, caches, spools
/var/log	Log files	Troubleshooting on disk logs
/var/lib	Persistent app state	Databases; package state
/run	Runtime since boot	PID files, sockets
/tmp	Scratch (often cleared)	Temporary files
/var/tmp	Scratch that survives reboot	Longer-lived temp
/proc, /sys	Kernel interfaces	Inspect processes and hardware
/mnt, /media	Mount points	Extra disks and removable media
/srv	Served site data	Optional web/FTP trees

Practice drills

Try these on a machine you control. Prefer read-only commands; use sudo only where listing needs it.

1. List the top of / and identify whether /bin is a real directory or a symlink into /usr.
2. Resolve the full path of the ls binary with type/which and readlink -f.
3. Use df -h to see whether /, /boot, /home, and /var share one filesystem or several.
4. Under /etc, find a directory that looks like a service you recognize (ssh, systemd, or a web server) and list it.
5. Compare ls -ld /tmp /var/tmp and explain which one is safer for a temp file that must survive reboot.

When you are ready to compare, here are solid answers — not the only ones, but clear and portable:

ls /
ls -ld /bin
# if you see /bin -> usr/bin, you are on merged /usr

type -a ls
which ls
readlink -f "$(which ls)"

df -h /
df -h /boot /home /var 2>/dev/null

ls /etc/ssh 2>/dev/null
ls /etc/systemd/system 2>/dev/null
# or: ls /etc | grep -E 'nginx|apache|httpd|ssh|systemd'

ls -ld /tmp /var/tmp
# /var/tmp is the usual choice when the file must survive reboot;
# /tmp is often cleared on reboot or is a tmpfs

If you can answer those five without hunting randomly, you already navigate Linux the way admins do: start from purpose (/etc for config, /var for growth, /usr for programs), confirm mounts with df, and only then dig with ls, find, or du. Keep the quick-reference table handy until the map becomes muscle memory.