Filesystem Layout (FHS) in Practice
Why Filesystem Layout Matters in Production
A production Linux server is not a random collection of files. It is a structured system designed to separate configuration, runtime state, logs, binaries, and user data. If you do not respect the Filesystem Hierarchy Standard (FHS), your deployments become fragile, backups become incomplete, and incidents become harder to debug.
The Core Directories You Must Understand
/etc — Configuration Only
This directory contains configuration files. Nothing else. Production rule: if something changes behavior, it should live in /etc.
- /etc/nginx/nginx.conf
- /etc/systemd/system/myapp.service
- /etc/ssh/sshd_config
Never store runtime files, logs, or secrets carelessly here. Treat it as declarative configuration.
/var — Mutable Data
/var is where runtime data lives. If your application writes something during execution, it likely belongs here.
- /var/log — logs
- /var/lib — application state
- /run — runtime pid/socket files
/srv — Application Data
Use /srv for service-owned data exposed externally.
/srv/myapp/releases/ /srv/myapp/current/
/usr vs /usr/local
/usr contains system-managed binaries. /usr/local contains manually installed software. Production rule: package manager owns /usr, you own /usr/local.
/run — Ephemeral Runtime
/run is cleared on reboot. Never store persistent data here.
Common Production Mistakes
- Storing logs inside application directory
- Writing temp files into /home
- Putting runtime data inside /etc
- Deploying apps inside /root
How to Inspect a Host Layout Quickly
lsblk df -h mount tree -L 1 /
Production Checklist
- Configs in /etc
- Logs in /var/log
- State in /var/lib
- App releases in /srv
- No writable root-owned surprises
Mental Model
Think of a Linux server as: Configuration → Runtime → Logs → State → Binaries. Respecting that separation makes backups, debugging, and rollbacks predictable.