Linux File System Hierarchy

Published: December 2025 | Topic: Filesystem Structure for DevOps

The Linux Filesystem Hierarchy Standard (FHS) provides a consistent directory structure across all Linux distributions. Understanding this hierarchy is crucial for DevOps engineers to efficiently locate files, troubleshoot issues, and manage systems. Whether you're configuring services, checking logs, or deploying applications, knowing where to find things saves time and prevents errors.

The Filesystem Hierarchy Standard (FHS)

What is FHS and Why It Matters

The Filesystem Hierarchy Standard defines the directory structure and directory contents in Linux operating systems. It's maintained by the Linux Foundation and provides consistency across distributions.

Key Benefits of FHS for DevOps:

• Predictability: Files are in the same locations across different distributions
• Efficiency: You know where to look for configuration files, logs, binaries, etc.
• Portability: Scripts and tools work across different Linux systems
• Security: Clear separation between system files and user data
• Maintainability: Organized structure makes system management easier

/
├── bin - Essential user binaries
├── sbin - System administration binaries
├── etc - Configuration files
├── home - User home directories
├── root - Root user's home
├── usr - User programs and data
├── var - Variable data (logs, databases)
├── tmp - Temporary files
├── opt - Optional application software
├── dev - Device files
├── proc - Process information
├── sys - Kernel information
└── boot - Boot loader files

Linux Filesystem Hierarchy Overview

/ (Root)

↓

bin

sbin

etc

home

↓

usr

var

opt

tmp

↓

dev

proc

sys

boot

Essential System Directories

Core Directories Every DevOps Engineer Must Know

/ Root Directory

The base of the filesystem tree. All other directories are subdirectories of root.

# Everything starts here
$ cd /
$ ls -l /

DevOps Tip: Never fill up the root partition! Keep at least 10-20% free.

/bin Essential Binaries

Essential command binaries needed for single-user mode and all users.

# Core commands available to all users
$ ls /bin/
bash, cat, cp, ls, mv, rm, etc.

Contents: Basic commands like ls, cp, mv, rm, cat, bash

/sbin System Binaries

Essential system binaries for system administration and repair.

# System administration commands
$ ls /sbin/
fdisk, fsck, ifconfig, init, reboot

Contents: System commands like fdisk, fsck, ifconfig, init, reboot

/etc Configuration Files

Host-specific system configuration files. The most important directory for DevOps.

# System and application configs
$ ls /etc/
passwd, fstab, hosts, nginx/, ssh/

DevOps Importance: Where 90% of system configuration happens.

/etc - The Configuration Directory

Mastering System Configuration

The /etc directory contains configuration files for the system and applications. As a DevOps engineer, you'll spend significant time here.

/etc
├── apt/ - APT package manager config
├── nginx/ - Nginx web server config
│ ├── nginx.conf
│ ├── sites-available/
│ └── sites-enabled/
├── apache2/ - Apache config
├── mysql/ - MySQL configuration
├── ssh/ - SSH server config
│ ├── sshd_config
│ └── ssh_config
├── systemd/ - Systemd config
├── hosts - Hostname to IP mapping
├── fstab - Filesystem mount table
├── passwd - User account info
├── group - Group definitions
├── sudoers - Sudo permissions
└── crontab - System cron jobs

Essential /etc Files for DevOps

File	Purpose	DevOps Use Case
/etc/hosts	Local hostname resolution	Testing DNS, overriding hostnames
/etc/fstab	Filesystem mount table	Configuring persistent mounts
/etc/resolv.conf	DNS resolver config	Setting DNS servers
/etc/ssh/sshd_config	SSH server config	Securing SSH access
/etc/sudoers	Sudo permissions	Managing admin access
/etc/crontab	System cron jobs	Scheduling maintenance tasks
/etc/environment	System environment vars	Setting global environment

/usr - User Programs and Data

The Secondary Hierarchy

/usr contains shareable, read-only data. Originally for "user" programs, now contains most user-space programs and data.

/usr
├── bin/ - Non-essential user binaries
├── sbin/ - Non-essential system binaries
├── lib/ - Libraries
├── lib64/ - 64-bit libraries
├── share/ - Architecture-independent data
├── local/ - Locally installed software
│ ├── bin/
│ ├── sbin/
│ └── lib/
├── include/ - Header files
└── src/ - Source code

/usr/bin vs /bin

/bin: Essential binaries needed for system boot and repair
/usr/bin: Non-essential binaries for normal operation

# /bin has core utilities
$ ls /bin/ | head -5
bash cat cp ls mv

# /usr/bin has applications
$ ls /usr/bin/ | head -5
python3 git curl wget nano

/usr/local - Local Software

For software installed locally (not by package manager). Follows same structure as /usr.

# Typical /usr/local structure
$ ls -la /usr/local/
drwxr-xr-x 2 root root 4096 bin
drwxr-xr-x 2 root root 4096 sbin
drwxr-xr-x 2 root root 4096 lib
drwxr-xr-x 2 root root 4096 etc

DevOps Use: Install custom or compiled software here to avoid conflicts with package manager.

/var - Variable Data

Files That Change During Operation

/var contains variable data files that change during system operation. Critical for logging and monitoring.

/var
├── log/ - Log files
│ ├── syslog
│ ├── auth.log
│ ├── nginx/
│ │ ├── access.log
│ │ └── error.log
│ └── mysql/
│ └── error.log
├── lib/ - Application state data
│ ├── mysql/ - Database files
│ └── docker/ - Docker data
├── spool/ - Queued data
│ ├── cron/ - Cron jobs
│ └── mail/ - Mail queue
├── cache/ - Application cache
├── tmp/ - Temporary files
└── www/ - Web content (sometimes)

/var/log - System Logs

The most important directory for troubleshooting. Contains all system and application logs.

# Essential log files
$ ls /var/log/
syslog, auth.log, kern.log,
dpkg.log, nginx/, mysql/

Monitor: Log rotation, disk usage, error patterns

/var/lib - Application Data

Persistent application data that survives reboots.

# Database and application data
$ ls /var/lib/
mysql/, postgresql/, docker/,
apt/, dpkg/

Backup: Critical data often lives here

/var/cache - Cache Data

Application cache that can be deleted (will be regenerated).

# Package manager caches
$ ls /var/cache/
apt/, yum/, man/

Cleanup: Safe to delete when low on disk space

⚠️ /var Disk Space Issues

/var can fill up quickly due to:

• Unrotated log files
• Growing database files
• Docker images and containers
• Mail queues

# Monitor /var usage
$ df -h /var
# Find large files in /var
$ du -sh /var/* | sort -hr

User and Home Directories

Home Directories and User Data

/home - Regular Users

Home directories for regular users. Each user gets a subdirectory.

/home
├── alice/
│ ├── .bashrc
│ ├── .ssh/
│ ├── Documents/
│ └── projects/
├── bob/
└── charlie/

# Navigate to home directory
$ cd ~
or
$ cd $HOME

/root - Superuser Home

The home directory for the root user. Separate from /home for security.

/root
├── .bashrc
├── .ssh/
├── scripts/
└── backups/

# Regular users can't access /root
$ ls -ld /root
drwx------ 10 root root 4096 Dec 1 10:00 /root
# ↑ Only root can access

Important Hidden Files in Home Directories

Hidden files (starting with .) contain user configuration:

# Common hidden files
$ ls -la ~ | head -10
.bashrc - Shell configuration
.bash_profile - Login configuration
.ssh/ - SSH keys and config
.gitconfig - Git configuration
.vimrc - Vim configuration
.profile - Environment variables

Special Purpose Directories

/tmp Temporary Files

World-writable directory for temporary files. Cleared on reboot.

# Sticky bit prevents file deletion by others
$ ls -ld /tmp
drwxrwxrwt 14 root root 4096 Dec 1 /tmp
# ↑ 't' indicates sticky bit

Use: Temporary files, process communication, cache

/opt Optional Software

For third-party or add-on application software.

# Typically contains self-contained apps
$ ls /opt/
google/, vscode/, idea/,
jetbrains-toolbox/

DevOps Use: Commercial software, proprietary tools

/dev Device Files

Special files representing hardware devices.

# Common device files
$ ls -l /dev/null /dev/zero /dev/random
crw-rw-rw- 1 root root 1, 3 /dev/null
crw-rw-rw- 1 root root 1, 5 /dev/zero
crw-rw-rw- 1 root root 1, 8 /dev/random

DevOps: Docker uses /dev for container devices

/proc Process Information

Virtual filesystem with process and system information.

# Live system information
$ cat /proc/cpuinfo
$ cat /proc/meminfo
$ ls /proc/[0-9]*/ -d | head -5
# Process directories

Monitoring: Real-time system stats and process info

/sys Kernel Information

Virtual filesystem for kernel parameters and hardware info.

# Kernel parameters and devices
$ ls /sys/
block/, bus/, class/, devices/, kernel/
$ cat /sys/class/net/eth0/operstate

Advanced: Tuning kernel parameters, hardware monitoring

/boot Boot Files

Files needed to boot the system: kernel, initramfs, bootloader.

# Boot files - DO NOT DELETE!
$ ls /boot/
vmlinuz-5.4.0-91-generic
initrd.img-5.4.0-91-generic
grub/

Warning: Critical for system boot. Keep multiple kernel versions.

Application Deployment Directories

Where to Deploy Applications in Linux

Location	Best For	Pros	Cons	Example
/opt	Self-contained applications	Isolated, easy to remove	Not in PATH by default	/opt/myapp/
/usr/local	Locally compiled software	Standard hierarchy, in PATH	Can conflict with packages	/usr/local/bin/myapp
/srv	Service data (web, FTP)	Clear purpose, organized	Less commonly used	/srv/www/
/var/www	Web applications	Traditional location	Mixed with other /var data	/var/www/html/
/home/user/app	User applications	No sudo needed	Not system-wide	/home/deploy/app/

Modern Web Application Deployment Structure

/opt
└── myapp
├── v1.0.0
│ ├── bin/ - Executables
│ ├── lib/ - Libraries
│ ├── config/ - Configuration
│ └── public/ - Web files
├── current -> v1.0.0 (symlink)
└── shared
├── logs/ - Application logs
├── uploads/ - User uploads
└── cache/ - Application cache

/etc
└── myapp
└── config.yml - Main config

/var
├── log/myapp - System logs
└── lib/myapp - Database

Container Filesystem Differences

How Containers Change the Filesystem

Containers have a different view of the filesystem than traditional systems:

Traditional Linux

/ (Root filesystem)
├── home
├── etc
├── var
├── usr
└── opt

• Single unified hierarchy
• All applications share same filesystem
• System-wide configuration in /etc
• Persistent data in /var and /home

Containerized Application

/ (Container root)
├── app - Application code
├── tmp - Temporary files
└── etc - Container config

/var/lib/docker (Host)
├── volumes - Persistent data
└── containers - Container storage

• Minimal filesystem (only what's needed)
• Isolated from host and other containers
• Volumes for persistent data
• Ephemeral by default

Container Filesystem Best Practices

# Typical Dockerfile structure
FROM alpine:latest
WORKDIR /app
COPY . .
RUN mkdir -p /app/data
VOLUME /app/data
EXPOSE 8080
CMD ["./app"]

• Keep container filesystems minimal
• Use volumes for persistent data
• Store configuration outside containers
• Follow FHS within containers when possible

Navigating and Exploring the Filesystem

Essential Navigation Commands

Basic Navigation

$ pwd # Print current directory
$ cd /path/to/dir # Change directory
$ cd ~ # Go to home directory
$ cd - # Go to previous directory
$ ls -la /path # List directory contents

Finding Files

$ find /etc -name "*.conf" # Find files by name
$ locate filename # Fast search using database
$ which command # Find command location
$ whereis command # Find command, source, man
$ type -a command # Show command type and location

Disk Usage

$ df -h # Disk free space
$ df -i # Inode usage
$ du -sh /path # Directory size
$ du -ah /path | sort -hr | head -20
# Largest files
$ ncdu /path # Interactive disk usage

Filesystem Information

$ mount # Show mounted filesystems
$ lsblk # List block devices
$ blkid # Show block device attributes
$ stat /path/to/file # File statistics
$ file /path/to/file # Determine file type

Troubleshooting Filesystem Issues

Common Problems and Solutions

Disk Full

Filesystem runs out of space.

# Check disk usage
$ df -h
# Find large files
$ du -ahx / | sort -rh | head -20

Common culprits: /var/log, /var/lib, /tmp

Inode Exhaustion

Filesystem has space but no inodes.

# Check inode usage
$ df -i
# Find directories with many files
$ find /path -type f | cut -d/ -f1-3 |
    sort | uniq -c | sort -rn

Fix: Delete many small files

Permission Issues

Can't access files or directories.

# Check permissions
$ ls -la /path
# Check user and groups
$ id
$ groups

Common: Web server can't read files, can't write to logs

Broken Symlinks

Symbolic links pointing to non-existent files.

# Find broken symlinks
$ find /path -type l ! -exec test -e {} \; -print
# Check symlink target
$ readlink /path/to/link

Common in: /etc, application directories

⚠️ Critical Files - Never Delete These!

• /etc/passwd - User account information
• /etc/shadow - Encrypted passwords
• /etc/fstab - Filesystem mount table
• /boot/ - Kernel and boot files
• /dev/null, /dev/zero - Special device files
• /bin/bash, /bin/sh - Shell binaries
• /sbin/init - System initialization
• /lib/, /lib64/ - System libraries

Always verify what you're deleting, especially when using rm -rf!

Best Practices for DevOps

Filesystem Management Guidelines

1. Follow FHS: Use standard directories for their intended purposes
2. Separate partitions: Consider separate partitions for /, /home, /var, /tmp
3. Monitor disk usage: Set up alerts for high disk usage (90%+)
4. Regular cleanup: Implement log rotation and cache cleanup
5. Backup critical data: Regularly backup /etc, /home, application data
6. Use symbolic links: For version management and configuration switching
7. Document custom locations: If you deviate from FHS, document why and where
8. Secure sensitive directories: Proper permissions on /etc, /root, /var/log
9. Test in staging: Test filesystem changes in staging before production
10. Automate deployment: Use configuration management for consistent filesystem setup

Practice Scenarios for DevOps Engineers

1. You get an alert that disk usage is at 95% on a production server. What's your troubleshooting process?
2. You need to deploy a new web application. Where would you put the application files, logs, and configuration?
3. Users report "Permission denied" when accessing uploaded files on a website. Where do you look and what do you check?
4. You need to switch between two versions of an application with zero downtime. How can you use symlinks to achieve this?
5. A containerized application can't write to disk. What directories should be mounted as volumes?
6. You suspect a security breach. Which log files would you check first and where are they located?
7. You're setting up a new server. Which directories would you put on separate partitions and why?
8. An application is failing with "Too many open files" but disk space is fine. What could be the issue?

Quick Reference: Directory Cheat Sheet

Configuration & System

/etc/ - Configuration files
/etc/ssh/ - SSH configuration
/etc/nginx/ - Nginx configuration
/etc/mysql/ - MySQL configuration
/boot/ - Boot files
/proc/ - Process information
/sys/ - Kernel information

Logs & Data

/var/log/ - System logs
/var/log/nginx/ - Nginx logs
/var/log/mysql/ - MySQL logs
/var/lib/ - Application data
/var/lib/mysql/ - Database files
/var/www/ - Web content
/var/tmp/ - Temporary files

Applications & Users

/usr/bin/ - User binaries
/usr/local/ - Local software
/opt/ - Optional software
/home/ - User home directories
/root/ - Root home directory
/srv/ - Service data
/tmp/ - Temporary files

Special Directories

/dev/ - Device files
/dev/null - Data sink
/dev/random - Random data
/mnt/ - Temporary mounts
/media/ - Removable media
/run/ - Runtime data
/sbin/ - System binaries

Key Takeaways

• FHS provides consistency: Files are in predictable locations across distributions
/etc is for configuration: System and application configuration files
• /var changes: Logs, databases, and variable data live here
• /usr is for software: User programs and shareable data
• /home is for users: User data and personal configurations
• Special directories: /dev, /proc, /sys provide access to hardware and kernel
• Containers are different: Minimal filesystems with volumes for persistence
• Monitor disk and inode usage: Both can cause system issues
• Follow standards: Makes systems more maintainable and portable

Mastering the Linux filesystem hierarchy will make you more efficient at system administration, troubleshooting, and application deployment. When in doubt about where to put something, consult the FHS standard or follow established patterns in your organization.