When you log in to a Linux server for the first time, it can feel like walking into a huge building with no signs on the doors. Directories like /etc, /var, /home and /opt are everywhere in tutorials, but what actually lives there and why does it matter for a sysadmin?
In this article we’ll walk through the basic filesystem layout of a typical Linux distribution, with a practical focus for system administrators: where to look for configuration, where applications write data, what you should back up, and what you should leave alone.
Understanding the Linux Filesystem Hierarchy
Most modern Linux distributions follow the Filesystem Hierarchy Standard (FHS), a set of conventions that describes what goes where. Not every distro follows it 100%, but it’s a good mental model. At the top, you have the root directory:
/ ← root of the filesystem
|-- bin
|-- boot
|-- dev
|-- etc
|-- home
|-- lib
|-- opt
|-- root
|-- sbin
|-- tmp
|-- usr
`-- var
As a sysadmin you don’t need to memorize every detail, but you should know the character of the important directories:
/etc– system-wide configuration/var– variable data (logs, queues, caches, spool)/home– user home directories/opt– optional third-party software/usr– userland programs and shared data/tmp– temporary files
Let’s go deeper into the most important ones.
/etc – The Brain of the System (Configuration)
If the server had a brain, it would be /etc. This is where global configuration lives. Whenever you install a package, it usually drops its config files somewhere under /etc.
Typical contents of /etc
$ ls /etc
adduser.conf
apt/
cron.d/
cron.daily/
cron.hourly/
default/
hostname
hosts
network/
nginx/
php/
ssh/
systemd/
...
Some classic examples:
/etc/hostname– the system hostname/etc/hosts– static host name lookups/etc/ssh/sshd_config– configuration for the OpenSSH server/etc/nginx/nginx.conf– main Nginx configuration/etc/php/*– PHP configuration files (php.ini and pool configs)
Best practices for /etc
- Always back up
/etc.
In a disaster recovery scenario, having/etcmeans you can quickly re-create your services on a fresh OS. - Use version control for important configs.
A simple Git repo (even local-only) for/etccan save hours: you can diff changes and roll back if needed. - Use drop-in directories when possible (e.g.
/etc/systemd/system/*.d/)
instead of editing big monolithic files whenever the software supports it.
Example: editing SSH configuration
To harden SSH, you’ll often edit /etc/ssh/sshd_config:
# Disable root login over SSH
PermitRootLogin no
# Allow only specific users
AllowUsers deploy admin
# Use key-based auth only
PasswordAuthentication no
After editing:
sudo systemctl restart sshd
Whenever you’re not sure where a service stores its config, look under /etc first.
/var – The Server’s “Working Area”
The name /var comes from “variable”. It contains data that changes frequently: logs, mail queues, caches, spool files, databases, and other runtime data.
$ ls /var
backups
cache
lib
log
mail
spool
tmp
www
Common subdirectories in /var
/var/log– log files (syslog, authentication logs, application logs)/var/lib– state data (databases, package metadata, runtime state)/var/cache– cached data that can usually be regenerated/var/spool– queued tasks (e.g. print jobs, mail queue)/var/www– default web content location on some distributions
/var/log – Your first stop when troubleshooting
When something breaks, /var/log is usually where you go.
$ ls /var/log
auth.log
cron.log
dmesg
kern.log
nginx/
syslog
wtmp
...
/var/log/auth.log(orsecureon some distros) – logins, sudo events, SSH authentication/var/log/syslog– general system messages/var/log/nginx/– web server logs (access, error)/var/log/journal/– binary logs forsystemd-journaldon some systems
Example: watch SSH logins in real time:
sudo tail -f /var/log/auth.log
Monitoring /var space usage
Because logs and runtime data grow over time, /var can fill up and break services. This is why many production setups use a separate partition for /var.
# Check disk usage
df -h /var
# Check which directories are heavy
sudo du -h /var | sort -h | tail
As a sysadmin, you should:
- Watch
/vardisk usage with monitoring tools (Prometheus, Nagios, etc.). - Configure log rotation (
logrotate) so logs don’t grow forever. - Know which services store important data in
/var/lib(e.g. databases, Wazuh indexer, etc.).
/home – Where Users Live
The /home directory is where regular users store their data. Each user typically has a subdirectory named after their username:
$ ls /home
alice
bob
deploy
Example: /home/alice will contain documents, SSH keys, dotfiles and so on:
/home/alice
|-- .bashrc
|-- .ssh/
|-- Documents/
|-- Downloads/
|-- Projects/
Why /home matters for sysadmins
- User data and profiles – most user-specific data and configuration lives here.
- Backups – for typical desktop or shared servers,
/homeis the main thing users care about if something fails. - Quotas – on multi-user systems you can enforce disk quotas on
/hometo avoid one user filling up the disk.
Example: creating a user with a home directory
sudo useradd -m -s /bin/bash alice
sudo passwd alice
The -m option creates /home/alice automatically based on the skeleton in /etc/skel.
Permissions in /home
By default, a user’s home directory is usually owned by that user:
$ ls -ld /home/alice
drwx------ 20 alice alice 4096 Nov 24 09:00 /home/alice
Important points:
- Other users cannot read another user’s home directory by default.
- As root, you can, but you should be careful with privacy and audit policies.
- On shared servers you might adjust permissions (for example, group-readable directories for project collaboration).
/opt – Optional and Third-Party Software
The /opt directory is intended for “optional” software – typically third-party or self-contained applications that don’t integrate tightly with the distribution’s package manager.
You’ll often see software vendors instructing you to extract their application under /opt, for example:
/opt
|-- grafana/
|-- teamviewer/
`-- some-enterprise-app/
When to use /opt
- For commercial or third-party software that ships as a tarball, installer or binary bundle.
- For custom applications that should live outside of the system’s package-managed paths.
- When you want a clean separation between “distribution-managed” software and “locally managed” software.
Example: installing a custom app to /opt
Imagine you have a binary called myapp from a vendor:
sudo mkdir -p /opt/myapp
sudo tar -xzf myapp-1.0.0-linux-x86_64.tar.gz -C /opt/myapp
# Optional: add a symlink to /usr/local/bin so it’s in the PATH
sudo ln -s /opt/myapp/myapp /usr/local/bin/myapp
Now all users can simply run:
myapp
From a maintenance perspective, keeping vendor apps in /opt makes it easier to:
- Identify non-standard software on the server.
- Back up or migrate specific applications.
- Remove them cleanly by deleting a single directory.
Bonus: /usr and /usr/local – System Software vs Local Customizations
While this article focuses on /etc, /var, /home and /opt, you’ll see a lot of activity under /usr and /usr/local too.
/usr – distribution-managed programs and data
The /usr tree typically contains:
/usr/bin– most user commands/usr/sbin– system binaries/usr/lib– shared libraries/usr/share– architecture-independent data
Most of this is managed by your package manager (apt, dnf, zypper, etc.). You usually don’t create or edit files here manually.
/usr/local – your playground
/usr/local is intended for locally installed software, built from source or installed manually by the admin:
/usr/local/bin– local executables/usr/local/sbin– local system binaries/usr/local/lib– local libraries
A common pattern:
sudo cp my-script.sh /usr/local/bin/my-script
sudo chmod +x /usr/local/bin/my-script
Now you have a script available system-wide without mixing it with distribution-managed files.
/tmp – Temporary Files You Can Usually Ignore (and Clean Up)
The /tmp directory is for temporary files. Many systems clean it automatically on boot or after a time period.
- Applications use it for short-lived data.
- You can safely delete your own temporary files here (but be careful with files in use).
# Show what’s inside /tmp
ls /tmp
# Remove your own old temporary files
rm /tmp/my-temp-file
On some setups, /tmp is a separate partition or even a tmpfs (in-memory filesystem) for speed and security.
Filesystem Layout and Partitions: Why It Matters
For small lab servers and VMs you might keep everything on one partition (/ only). For production, it often makes sense to split certain directories into their own filesystems:
/var– so logs and variable data can’t fill the entire root filesystem/home– to simplify backups and user data management/optor/srv– for application data and services
You can see how your system is currently partitioned:
lsblk
df -h
As a sysadmin, designing a good partition layout is part of making the system resilient and easier to maintain.
What to Back Up – and What You Can Reinstall
Not everything in the filesystem is equally important. In many cases you can reinstall the OS and packages,
but you cannot easily re-create configuration and data.
High priority for backups
- /etc – configuration of almost everything
- /home – user data, SSH keys, personal configs
- /var/lib – service data (databases, Wazuh indexer, etc.)
- /opt – third-party apps and custom installations
Lower priority (can be re-created)
/usr– binaries and libraries installed from packages/var/cache– caches that can be regenerated/tmp– temporary files
A simple backup strategy for a small server might include:
/etc
/home
/var/lib
/opt
combined with a list of installed packages, so you can quickly rebuild:
# On Debian/Ubuntu
dpkg --get-selections > packages.list
Summary: Think of the Filesystem as a City Map
You don’t have to know every street, but as a sysadmin you should know the main districts:
- /etc – configuration hub for the whole system
- /var – dynamic data: logs, queues, runtime state
- /home – where users live and store their files
- /opt – third-party and optional software
- /usr and /usr/local – system programs vs. local custom tools
- /tmp – temporary workspace for applications
Once you get comfortable with this layout, many tasks become easier:
- Finding the right config file without Googling every time.
- Knowing where to look when something breaks.
- Designing backups that actually protect what matters.
- Keeping systems clean, predictable and easier to migrate.
The filesystem is one of the first things you should master on your Linux journey as a sysadmin. After that, tools like package managers, systemd, logging and monitoring will all start to make much more sense, because you know where they keep their configuration and data.