The Linux directory layout: /etc, /var, /usr explained
Know where configuration, data, logs and programs live, so you know what to edit and what to back up.
Part 4 of 12 in Linux basics for self-hosters. Last updated
In short: Configuration lives in /etc, changing data such as logs, databases and caches in /var, installed programs in /usr, your own files in /home, and runtime files that vanish at reboot in /run. On current distributions /bin, /sbin and /lib are only links into /usr. For a home server, the directories to back up are /etc, /home, /srv (or wherever your service data lives) and parts of /var/lib.
The map in one table
Linux has one tree that starts at /. Disks, USB sticks and network shares do not
get drive letters; they are mounted somewhere inside that tree. The layout is standardised in
the Filesystem Hierarchy Standard
and, for systemd distributions, in file-hierarchy(7).
| Directory | What lives there | You edit it? |
|---|---|---|
/etc | System-wide configuration: fstab, ssh/sshd_config, systemd/system/ | Yes, this is your side |
/usr | Installed programs (/usr/bin), libraries (/usr/lib), shared data and documentation | No, the package manager owns it |
/usr/local | Programs and scripts you installed by hand | Yes |
/var | Data that changes: /var/log, /var/lib (databases, container storage), /var/cache | Rarely by hand; back up /var/lib |
/home | One directory per user, with their files and personal settings (dotfiles) | Yes, your own |
/root | The home directory of the root user | Rarely |
/srv | Data a server serves: a good home for service data such as /srv/media | Yes |
/opt | Self-contained third-party software that brings its own directory tree | Only for that software |
/mnt, /media | Mount points: /mnt for things you mount yourself, /media for removable media | Yes, create mount points here |
/tmp | Temporary files; often a tmpfs in memory that is empty after a reboot | No |
/run | Runtime data since boot: PID files, sockets, locks (/var/run and /var/lock point here) | No |
/proc, /sys | Virtual files the kernel creates to show processes and hardware | Read, do not write |
/dev | Device files: disks (/dev/sda, /dev/nvme0n1), terminals, /dev/null | No |
/boot | Kernels, the initramfs and boot loader files | No, updates manage it |
Why /bin points to /usr/bin
Old guides describe /bin, /sbin and /lib as separate
directories for "essential" programs. On openSUSE, Fedora, Arch, Ubuntu and Debian 12 and newer
they are now symbolic links into /usr, a change called the usr merge. Check it
yourself:
# openSUSE Tumbleweed
$ ls -ld /bin /sbin /lib /lib64
lrwxrwxrwx 1 root root 7 Mar 2 2026 /bin -> usr/bin
lrwxrwxrwx 1 root root 7 Mar 2 2026 /lib -> usr/lib
lrwxrwxrwx 1 root root 9 Mar 2 2026 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 8 Mar 2 2026 /sbin -> usr/sbin
# Debian 12
$ ls -ld /bin /sbin /lib /lib64
lrwxrwxrwx 1 root root 7 Jan 13 2025 /bin -> usr/bin
lrwxrwxrwx 1 root root 7 Jan 13 2025 /lib -> usr/lib
lrwxrwxrwx 1 root root 9 Jan 13 2025 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 8 Jan 13 2025 /sbin -> usr/sbinReal output on openSUSE Tumbleweed and Debian 12, 2026-09-28; user and host names and addresses redacted.
The l at the start and the arrow mean "this is a link". A script with
#!/bin/bash keeps working; it just ends up in /usr/bin/bash. One
result is handy: everything the distribution installed sits under /usr, and your
changes sit under /etc and /var.
Where configuration really lives
More and more packages ship their default configuration under /usr and only read
/etc for your changes. That keeps updates from overwriting your edits.
- systemd units: packages put services in
/usr/lib/systemd/system/; your own units and overrides go in/etc/systemd/system/. Do not edit the file under/usr: runsudo systemctl edit sshd.service, which creates an override drop-in that survives updates. - openSUSE's
/usr/etc: openSUSE moves many defaults, such as/usr/etc/sudoers, out of/etc. If/etc/sudoersseems to be missing, that is why. Put your changes in a new file under the matching.ddirectory in/etc, such as/etc/sudoers.d/.$ grep -E '^[^#]*targetpw' /usr/etc/sudoers /etc/sudoers /usr/etc/sudoers:Defaults targetpw # ask for the password of the target user i.e. root grep: /etc/sudoers: No such file or directoryReal output on openSUSE Tumbleweed, 2026-09-28; user and host names and addresses redacted.
- Per-user settings: dotfiles in your home directory, mostly under
~/.config. User services live in~/.config/systemd/user/.
Where podman keeps its files
| What | Rootless (your user) | Rootful (root) |
|---|---|---|
| Quadlet files | ~/.config/containers/systemd/ | /etc/containers/systemd/ |
| Images and containers | ~/.local/share/containers/storage/ | /var/lib/containers/storage/ |
| Named volumes | ~/.local/share/containers/storage/volumes/ | /var/lib/containers/storage/volumes/ |
| Podman settings | ~/.config/containers/ | /etc/containers/ |
podman volume inspect NAME --format '{{.Mountpoint}}' prints the exact path of a
volume, and podman info shows where your own storage is:
$ podman info --format '{{.Store.GraphRoot}} {{.Store.VolumePath}}'
/home/user/.local/share/containers/storage /home/user/.local/share/containers/storage/volumesReal output on openSUSE Tumbleweed, podman 6.0.2, 2026-09-28; user and host names and addresses redacted.
Write quadlets by hand, or convert a docker-compose file with the compose to quadlet converter and check the result with the systemd unit explainer.
What to back up
A reinstall gives you /usr back for free. What it cannot give you back:
/etc: all your system configuration, small and precious./home: including~/.config/containers/systemd/and rootless volumes./srvor wherever your service data lives, such as a media library.- The parts of
/var/libthat belong to your services, such as rootful volumes and databases.
Skip /proc, /sys, /dev, /run and
/tmp: they are rebuilt at every boot. Network shares usually live under
/mnt; the fstab generator for NAS shares
writes the line that mounts one at boot. How to copy it all safely is in
rsync and tar done right.
Common mistakes
Editing a unit file under /usr/lib/systemd
It works until the next package update silently puts the original back. Use
sudo systemctl edit name.service for a drop-in, or copy the unit to
/etc/systemd/system/ if you want to replace it completely.
Storing service data in /tmp
On openSUSE Tumbleweed and Fedora /tmp lives in memory, so a reboot empties it.
Everywhere else, systemd-tmpfiles deletes old files there on a schedule. Keep data in
/srv, /var/lib or a volume.
Filling the root file system with a forgotten mount point
If a NAS share is not mounted, /mnt/nas is just an empty directory on your
system disk, and a backup job will happily fill it. Check with findmnt /mnt/nas
before writing, and see the disk space guide for
finding what filled the disk.
Frequently asked questions
What is the difference between /usr/bin and /usr/local/bin?
/usr/bin belongs to the package manager: every file there came from a package and an update may replace it. /usr/local/bin is yours: put scripts and programs you installed by hand there, and the package manager will never touch them.
Is it safe to delete files in /tmp?
Files in /tmp are temporary by definition, but a running program may still use them, so do not empty it by hand while the system runs. On many current distributions /tmp is a tmpfs in memory and is cleared at every reboot; systemd-tmpfiles also removes old files on a schedule.
Where are log files on Linux?
Most services on a systemd distribution log to the journal, which you read with journalctl; it is stored in /var/log/journal. Some programs still write plain text files to /var/log, for example the zypper history in /var/log/zypp/history.
Why is there no lost+found directory on my system?
lost+found is created when an ext2, ext3 or ext4 file system is made, as a place for files that fsck recovers. btrfs has no such directory and XFS only creates one during a repair, so an openSUSE system on the default btrfs has none. It is not something you need to create.