The Linux Filesystem Explained: Where Everything Lives and Why

If you come from Windows or macOS, the Linux filesystem looks chaotic. Instead of C:\Program Files and C:\Users, you see directories with short, cryptic names: etc, var, opt, usr, tmp. Every one of them has a specific purpose defined by the Filesystem Hierarchy Standard. Once you understand the reasoning, the layout becomes intuitive. Here is what every directory on your self-hosting server actually contains and why.

The Root Directory: /

Everything starts at /. It is the top of the tree. Every file and directory on the system is a descendant of /. There is no C: drive or D: drive in Linux. Everything is one unified tree, regardless of how many physical disks are attached.

/home -- User Files

The home of human users. Your personal files, SSH keys, and shell configuration live here. Each user gets a subdirectory like /home/alice or /home/bob. On a server, your admin user home lives here. On a desktop, your documents, downloads, and desktop files live here.

For self-hosting: install nothing here. This is for user data, not applications.

/etc -- Configuration Files

System-wide configuration files. Every program that needs persistent settings stores them here. Nginx configuration lives in /etc/nginx. SSH server configuration lives in /etc/ssh/sshd_config. Systemd service definitions live in /etc/systemd/system. The hostname lives in /etc/hostname.

The name stands for et cetera, from the early days of Unix when this directory was a catch-all. Today it is exclusively for configuration files. Nothing executable lives here. Nothing temporary lives here. Only configs.

For self-hosting: when a tutorial tells you to edit a configuration file, it is almost certainly in /etc. Learn this directory well.

/var -- Variable Data

Files that change during normal system operation. Logs live in /var/log. Databases often store their data in /var/lib: PostgreSQL uses /var/lib/postgresql, MySQL uses /var/lib/mysql. Docker stores its entire data directory at /var/lib/docker. Email spools, print queues, and lock files live here.

The name stands for variable. Data here grows and shrinks as the system runs. This is the directory that fills up and causes outages when logs are not rotated or Docker images accumulate.

For self-hosting: monitor /var/lib/docker closely. It will be the largest directory on your server. Run docker system df to see what is using space inside Docker, and docker system prune to clean up unused images, containers, and volumes.

/opt -- Optional Application Software

Third-party and add-on software packages. Store Docker Compose stacks in /opt/stacks. This is good practice because /opt is explicitly intended for optional application software that is not part of the base operating system.

For self-hosting: create /opt/stacks and store every docker-compose.yml in its own subdirectory. Example: /opt/stacks/nextcloud/compose.yml. Dockge defaults to /opt/stacks. This keeps all your application definitions in one predictable location.

/tmp -- Temporary Files

Files that do not need to survive a reboot. Any program can write here. The system may clear this directory on reboot or periodically. Use /tmp for short-lived files like downloads you need once, temporary archives, or scratch space.

For self-hosting: never store anything important in /tmp. It is not backed up and may disappear without warning.

/usr -- Unix System Resources

Shared, read-only application files. Executables for most programs live in /usr/bin. System libraries live in /usr/lib. Shared data like documentation, icons, and locale files live in /usr/share. The name stands for Unix System Resources.

On modern systems, /bin, /sbin, and /lib are often symbolic links into /usr as part of the merged /usr scheme. You do not need to worry about the distinction. Just know that installed programs live somewhere under /usr.

For self-hosting: you will rarely touch anything in /usr directly. It is managed by your package manager (apt, yum, pacman).

/boot -- Bootloader Files

The Linux kernel and bootloader configuration. When your server starts, the bootloader loads the kernel from /boot. These files are critical. If /boot fills up from old kernel versions accumulating, the system may fail to boot after an update.

For self-hosting: occasionally run sudo apt autoremove to clean up old kernels from /boot.

/dev -- Device Files

Virtual files representing hardware devices. /dev/sda is your first hard drive. /dev/tty is your terminal. /dev/null is a black hole you can redirect output into. /dev/urandom generates random numbers. These are not real files. They are interfaces to the kernel that look like files.

For self-hosting: you will use /dev/null to discard unwanted output and /dev/urandom to generate random keys for your applications.

/proc and /sys -- Kernel Interfaces

Virtual filesystems that expose kernel and process information. /proc/cpuinfo shows CPU details. /proc/meminfo shows memory information. /proc/PID/ contains information about each running process. These files do not exist on disk. They are generated by the kernel when you read them.

For self-hosting: cat /proc/cpuinfo to check your CPU model and core count. cat /proc/meminfo for detailed memory statistics beyond what free -h shows.

/run -- Runtime Data

Files describing the system since it booted. Process ID files, socket files, and lock files. This directory is cleared on every reboot. It is stored in RAM (tmpfs), not on disk, so it is fast but volatile.

For self-hosting: you will rarely interact with /run directly. System services use it automatically.

Quick Reference Table

If the Linux filesystem feels like a maze, VPS1 manages your server for you. We handle the directory structure, the permissions, and the backups. You never need to memorize where /var/lib lives.