Linux File System Explained: Complete Guide to Directories, Permissions, Mounts and Storage

Linux File System Explained: Complete Guide to Directories, Permissions, Mounts and Storage

Understanding the Linux file system is one of the most important skills for anyone working with Linux servers, cloud infrastructure, DevOps, cybersecurity, containers, virtualization, or system administration.

Unlike Windows environments, where users commonly interact with drive letters such as C: and D:, Linux organizes files, directories, devices, mounted storage, processes, and many kernel interfaces under a single hierarchical directory tree beginning at:

/

Everything connects to this hierarchy.

Applications, configuration files, user data, devices, logs, temporary files, mounted disks, sockets, and virtual kernel interfaces are exposed through a consistent path-based model.

This architecture is one reason Linux works so effectively across servers and infrastructure. An administrator can manage local disks, virtual disks, cloud block volumes, network storage, containers, and special kernel interfaces through the same hierarchical namespace.

If you are building your Linux administration foundation, the Linux Server Administration Guide covers the broader server-management workflow. This guide focuses specifically on the Linux filesystem: directories, filesystem types, permissions, ownership, mount points, inodes, links, LVM, security, performance, and troubleshooting.

Many common Linux directory conventions are described by the Filesystem Hierarchy Standard.

Linux File System at a Glance

A simplified Linux filesystem hierarchy looks like this:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
└── var

The exact contents vary between distributions and installations.

Modern Linux distributions may also implement usr-merge, where directories such as /bin and /sbin are symbolic links into /usr.

Understanding this structure provides the foundation for almost every Linux administration task.

1. What Is the Linux File System?

The term Linux file system can refer to several related concepts.

At a practical level, it includes:

• The hierarchical directory structure
• Filesystem implementations
• File metadata
• Permissions and ownership
• Mount points
• Kernel interfaces
• Storage devices
• Utilities used to manage files and storage

It is important to distinguish between the Linux filesystem hierarchy and a filesystem type.

For example:

/
├── etc
├── home
├── var
└── usr

is part of the directory hierarchy.

Meanwhile:

ext4
XFS
Btrfs
tmpfs
NFS

are filesystem types or filesystem mechanisms.

A directory such as /var might reside on the root ext4 filesystem on one server but on a separate XFS logical volume on another.

The path remains /var even though the underlying storage architecture is different.

2. Everything Starts at /

The top of the Linux filesystem hierarchy is:

/

This is the root directory.

For example:

/home/alice/document.txt

can be visualized as:

/
└── home
    └── alice
        └── document.txt

A second disk could be mounted at:

/data

Applications could then access it through:

/data/database/

The storage behind /data might be:

• A disk partition
• An LVM logical volume
• Another physical disk
• A virtual disk
• Network storage
• A cloud block-storage volume

Applications normally work with the mounted path rather than needing to understand every storage layer beneath it.

3. Absolute Paths vs Relative Paths

An absolute path begins with /.

Example:

/etc/ssh/sshd_config

It identifies the same filesystem location regardless of the current working directory.

A relative path does not begin with /.

Example:

documents/report.txt

Its meaning depends on the current directory.

Check your current directory with:

pwd

If it returns:

/home/alice

then:

cat documents/report.txt

refers to:

/home/alice/documents/report.txt

Understanding this difference is particularly important in shell scripts, automation, application configuration, and deployment workflows.

4. Important Linux Directories

Linux administrators should understand the major top-level directories.

The authoritative Filesystem Hierarchy Standard provides additional detail about the intended purpose of many standard directories.

5. /bin and /sbin

Historically, /bin contained essential user commands and /sbin contained important system-administration utilities.

Modern distributions may use symbolic links such as:

/bin -> usr/bin

and:

/sbin -> usr/sbin

Check with:

ls -ld /bin /sbin

This is part of the modern usr-merge architecture.

Therefore, administrators should not assume that /bin, /sbin, /usr/bin, and /usr/sbin always represent physically separate trees.

6. /etc: System Configuration

/etc is one of the most important directories for Linux administrators.

Typical examples include:

/etc/hostname
/etc/hosts
/etc/fstab
/etc/passwd
/etc/group
/etc/shadow
/etc/ssh/
/etc/systemd/
/etc/resolv.conf

For example:

cat /etc/hostname

displays the configured hostname.

OpenSSH server configuration is commonly stored at:

/etc/ssh/sshd_config

The official OpenSSH documentation provides authoritative information about SSH server and client configuration.

Because /etc contains critical configuration, administrators should understand the affected service before editing files and should back up important configurations before major changes.

7. /home: User Data

Ordinary user home directories normally exist under:

/home

Example:

/home/
├── alice/
├── bob/
└── developer/

A home directory may contain:

Documents/
Downloads/
.config/
.ssh/
.bashrc

List hidden files with:

ls -la /home/alice

Linux hidden filenames generally begin with a dot:

.bashrc
.profile
.ssh
.config

Home directories may contain SSH keys, scripts, credentials, application configuration, development environments, and personal data, so permissions and ownership matter.

8. /root: The Root User’s Home

The directory:

/root

is normally the root user’s home directory.

It is not the same as:

/

/ is the top of the entire filesystem hierarchy.

/root is one directory inside that hierarchy.

9. /usr: User-Space Software

/usr contains a large portion of user-space software and associated data.

Important locations include:

/usr/bin
/usr/sbin
/usr/lib
/usr/share
/usr/local

/usr/local is traditionally useful for locally installed software that is separate from the distribution’s standard package-managed files.

10. /var: Variable Data

/var contains data that changes during normal system operation.

Examples include:

/var/log
/var/cache
/var/lib
/var/spool
/var/tmp

Logs are particularly important:

/var/log

Depending on the distribution, you may encounter:

/var/log/auth.log
/var/log/syslog
/var/log/messages
/var/log/kern.log

On systemd systems, investigate the journal with:

journalctl

or a particular service:

journalctl -u ssh

The journalctl manual documents filtering by services, boots, priorities, processes, and other fields.

/var is also one of the first places to investigate when a server unexpectedly consumes large amounts of storage.

11. /tmp: Temporary Files

/tmp is intended for temporary data.

Applications may use it for temporary downloads, working files, sockets, installation files, or short-lived operations.

Do not assume that files stored in /tmp will survive reboot or automated cleanup.

Important persistent information should not be stored there.

12. /boot: Boot Components

/boot contains files involved in starting the operating system.

Typical contents can include:

vmlinuz
initramfs
grub/

Inspect it with:

ls -lah /boot

If /boot is a separate filesystem, insufficient free space can interfere with kernel or package updates.

13. /dev: Devices as Files

Linux exposes many devices through file-like interfaces under:

/dev

Examples include:

/dev/sda
/dev/nvme0n1
/dev/null
/dev/random
/dev/tty

List block devices with:

lsblk

Example:

NAME        SIZE TYPE MOUNTPOINTS
nvme0n1     500G disk
├─nvme0n1p1   1G part /boot
└─nvme0n1p2 499G part /

The names depend on hardware, storage drivers, virtualization, and cloud architecture.

The Linux kernel documentation provides deeper technical documentation for kernel subsystems and devices.

14. /proc: Processes and Kernel Information

/proc is a virtual filesystem.

For example:

cat /proc/cpuinfo

provides CPU information, while:

cat /proc/meminfo

provides memory information.

Processes appear through numeric directories:

/proc/1
/proc/1234
/proc/5678

Much of /proc is generated dynamically by the kernel rather than representing ordinary files stored on disk.

15. /sys: Kernel and Hardware Interfaces

/sys exposes information about devices, drivers, buses, and kernel objects.

For example:

ls /sys/class/net

may return interfaces such as:

eth0
lo

or predictable names such as:

ens18
enp0s3

Filesystem administration frequently intersects with networking. The Computer Networking Explained guide covers the networking foundation behind interfaces, addressing, switches, routers, and network communication.

16. /run: Runtime State

/run contains runtime information generated after boot.

Examples include:

• PID information
• Unix sockets
• Service runtime state
• Temporary locks

It is commonly backed by tmpfs, so it should not be treated as persistent application storage.

17. /media, /mnt, /opt and /srv

/media is often used for automatically mounted removable media.

/mnt is traditionally used for temporary administrator-controlled mounts.

For example:

sudo mount /dev/sdb1 /mnt

/opt may contain optional third-party software:

/opt/application/

/srv is intended for data served by system services and might contain structures such as:

/srv/www
/srv/ftp
/srv/data

Actual usage differs between distributions and organizations.

18. Linux Filesystem Types

The directory hierarchy is separate from the filesystem implementation storing the data.

Common filesystem types include:

Filesystem selection should consider workload, distribution support, performance, recovery, reliability, and operational tooling.

19. ext4, XFS and Btrfs

ext4 remains a common general-purpose Linux filesystem.

Check the filesystem backing / with:

findmnt -T /

or:

df -Th /

Example:

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4  100G   35G   60G  37% /

XFS is designed for scalability and is widely encountered in enterprise Linux environments.

Btrfs is a copy-on-write filesystem offering capabilities such as subvolumes, snapshots, checksums, and compression.

The right choice depends on the workload:

Workload
   ↓
Performance Requirements
   ↓
Reliability Requirements
   ↓
Backup / Recovery Requirements
   ↓
Operational Support
   ↓
Filesystem Choice

The Red Hat Enterprise Linux documentation provides extensive enterprise storage documentation, while the filesystem-specific documentation supplied by your Linux distribution should be consulted before production changes.

20. What Is a Mount Point?

A mount point is a directory through which another filesystem becomes accessible.

Suppose a filesystem exists on:

/dev/sdb1

and should become available at:

/data

Mount it:

sudo mount /dev/sdb1 /data

Verify:

findmnt /data

Conceptually:

Physical / Virtual Storage
          ↓
       Partition
          ↓
      Filesystem
          ↓
        Mount
          ↓
        /data
          ↓
     Applications

This is how Linux integrates different storage devices into one hierarchy.

21. Mounting Does Not Copy Files

Suppose /data already contains files and another filesystem is mounted there:

sudo mount /dev/sdb1 /data

The underlying files are not automatically deleted.

They are hidden by the mounted filesystem while that mount remains active.

After:

sudo umount /data

the original contents can become visible again.

This behavior is important when investigating apparently missing files.

22. Persistent Mounts with /etc/fstab

Persistent filesystem mounts are commonly configured through:

/etc/fstab

A simplified entry could be:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data ext4 defaults 0 2

Inspect UUIDs with:

sudo blkid

or:

lsblk -f

Using stable identifiers such as UUIDs can be preferable to relying exclusively on names such as /dev/sdb1.

The standard format is documented in the fstab(5) manual.

A safer editing workflow is:

sudo cp /etc/fstab /etc/fstab.bak
sudo nano /etc/fstab
sudo mount -a

Investigate any error before rebooting.

23. Linux File Permissions

Linux permissions determine who can read, write, or execute filesystem objects.

Check them with:

ls -l

Example:

-rw-r--r-- 1 alice developers 2048 Sep 18 report.txt

The permissions are:

-rw-r--r--

Conceptually:

- rw- r-- r--
  │   │   │
  │   │   └── Others
  │   └────── Group
  └────────── Owner

Linux permissions form an important part of server security, particularly for application files, SSH material, web content, configuration, and shared directories.

24. Numeric Permissions

The basic numeric values are:

read     = 4
write    = 2
execute  = 1

Therefore:

7 = read + write + execute
6 = read + write
5 = read + execute
4 = read
0 = no permissions

For example:

chmod 755 script.sh

means:

Owner:  rwx
Group:  r-x
Others: r-x

Permissions should reflect actual access requirements.

25. Why chmod 777 Is Usually a Bad Fix

A common reaction to a permission error is:

chmod 777 file

This gives broad access and can increase security exposure.

Instead, determine:

Who needs access?
       ↓
What operation is required?
       ↓
Which user runs the process?
       ↓
Which group should own the resource?
       ↓
Apply minimum required permissions

This follows the principle of least privilege and complements the security concepts discussed in Network Security Basics.

26. Ownership

Every ordinary file normally has an owner and group.

Inspect them:

ls -l file.txt

Change owner and group:

sudo chown alice:developers file.txt

Change the owner:

sudo chown alice file.txt

Change the group:

sudo chgrp developers file.txt

Recursive changes are possible:

sudo chown -R alice:developers /data/project

Use recursive operations carefully on production servers.

27. Directory Permissions

Directory permissions behave differently from ordinary file permissions.

For directories:

r = list entries
w = create/delete/rename entries
x = traverse the directory

A user may have permission to read a file but still be unable to reach it because a parent directory lacks the required traversal permission.

This is a common source of web-server and application errors.

28. SUID, SGID and Sticky Bit

Linux supports special permission mechanisms including:

• SUID
• SGID
• Sticky bit

For example:

ls -ld /tmp

may show permissions ending in:

t

The sticky bit is especially important for shared writable directories because it affects who can remove or rename entries.

Special permissions should not be modified without understanding their security implications.

29. Linux ACLs

Traditional owner/group/other permissions are sometimes insufficient.

Linux Access Control Lists provide additional granularity.

Inspect an ACL:

getfacl file.txt

Grant a specific user read access:

setfacl -m u:bob:r file.txt

ACLs can be useful for shared application and departmental environments without abandoning the standard Unix permission model.

30. Symbolic Links and Hard Links

A symbolic link points to another path:

ln -s /var/www/site/current /var/www/site/live

Inspect it:

ls -l /var/www/site/live

A hard link instead creates another directory entry pointing to the same underlying inode:

ln original.txt copy.txt

Compare inode numbers:

ls -li original.txt copy.txt

Hard links and symbolic links behave differently, particularly across filesystem boundaries and when target paths are removed.

31. What Is an Inode?

An inode stores filesystem metadata associated with an object.

Depending on the filesystem, this can include:

• File type
• Permissions
• Ownership
• Timestamps
• Size
• References to file data

A simplified model is:

Filename
   ↓
Directory Entry
   ↓
Inode
   ↓
Metadata + Data References
   ↓
File Data

This explains why multiple hard links can reference the same underlying file.

32. Inode Exhaustion

A filesystem can have free storage capacity yet still be unable to create new files if available inodes are exhausted.

Check:

df -i

Compare that with:

df -h

This distinction is critical when diagnosing:

No space left on device

A useful troubleshooting model is:

No space left on device
          |
          +----> df -h   → capacity
          |
          +----> df -i   → inodes

Large numbers of tiny files can exhaust inodes before consuming all available bytes.

33. Understanding du, df, lsblk and findmnt

These commands answer different questions.

Find large directories under /var:

sudo du -xhd1 /var

Find files larger than 1 GB:

sudo find /var -type f -size +1G -ls

A proper storage investigation normally combines multiple tools rather than relying on one command.

34. The Linux Storage Stack

A Linux application usually does not communicate directly with a physical disk.

A simplified storage stack may look like:

Application
    ↓
File
    ↓
Filesystem
    ↓
Logical Volume
    ↓
Partition / Block Device
    ↓
Virtual / Physical Disk
    ↓
Storage Infrastructure

In virtualized or cloud environments, additional layers can exist beneath the block device.

Understanding these layers helps explain why a filesystem problem is not always a physical-disk problem.

35. Logical Volume Manager (LVM)

LVM adds a flexible storage-management layer.

Its basic model is:

Physical Volume
      ↓
Volume Group
      ↓
Logical Volume
      ↓
Filesystem
      ↓
Mount Point

Useful commands include:

pvs
vgs
lvs

Inspect the complete block-device layout with:

lsblk

LVM can make it easier to allocate and extend storage, but administrators should understand the complete storage chain before making production changes.

36. Extending Storage with LVM

A conceptual expansion workflow might be:

New Storage
     ↓
Physical Volume
     ↓
Volume Group
     ↓
Logical Volume
     ↓
Filesystem Growth

Before changing storage, inspect:

lsblk
pvs
vgs
lvs
df -Th

The exact commands required to expand the filesystem depend on the filesystem and underlying storage architecture.

Do not execute storage modification commands blindly on production systems.

37. Network File Systems

Linux can mount remote storage using technologies such as:

• NFS
• SMB/CIFS

An NFS mount might conceptually look like:

sudo mount -t nfs server:/export/data /mnt/data

The application then accesses:

/mnt/data

as part of the normal Linux directory tree.

Network filesystems introduce additional dependencies including:

• Network latency
• Server availability
• Authentication
• Permissions
• Locking
• DNS
• Firewall policy

Because of these dependencies, filesystem troubleshooting can quickly become network troubleshooting. The TCP/IP Explained guide provides useful background when investigating connectivity-related storage failures.

38. Linux Filesystem Security

The filesystem is part of the server’s security boundary.

Important controls include:

Ownership
Permissions
ACLs
SELinux / AppArmor
Mount options
Encryption
Auditing
Backups
File-integrity monitoring

Traditional Unix permissions are only one layer.

Systems using SELinux or AppArmor can impose additional security restrictions even when standard ownership and permissions appear correct.

This is why troubleshooting an application access problem should not stop at chmod.

39. Security-Related Mount Options

Mount options can modify filesystem behavior.

Depending on the workload, administrators may consider options such as:

nodev
nosuid
noexec
ro

However, restrictive options can break legitimate applications.

A better workflow is:

Security Requirement
        ↓
Application Requirements
        ↓
Test
        ↓
Deploy
        ↓
Monitor

Do not apply security options indiscriminately across every filesystem.

40. Filesystem Encryption

Linux storage can be protected using technologies such as LUKS and dm-crypt.

A simplified architecture is:

Application
    ↓
Filesystem
    ↓
Encrypted Block Layer
    ↓
Partition
    ↓
Storage Device

Encryption helps protect data at rest if the underlying storage is obtained by an unauthorized party.

It does not mean data remains encrypted from applications after the volume has been legitimately unlocked.

Encryption therefore complements rather than replaces permissions, authentication, application security, and access control.

41. Finding Files

The find command is one of the most useful Linux administration tools.

Find by filename:

find /var -name "*.log"

Find large files:

find /var -type f -size +500M

Find recently modified files:

find /var -type f -mtime -1

Find files owned by a user:

find /home -user alice

Be especially careful when combining find with commands that modify or delete files.

42. Searching File Contents

Use grep to search text:

grep "error" /var/log/application.log

Recursive search:

grep -R "database" /etc/

Case-insensitive search:

grep -Ri "failed" /var/log/

find and grep can also be combined:

find /var/log -type f -name "*.log" -exec grep -H "error" {} \;

These tools become particularly useful during application and server troubleshooting.

43. File Attributes

Some Linux filesystems support additional attributes beyond standard permissions.

Inspect them with:

lsattr file.txt

chattr can modify supported attributes.

For example:

chattr +i file.txt

can mark a supported file as immutable.

Use this carefully. Attributes can create confusing troubleshooting situations when administrators forget that they were applied.

44. Deleted Files Still Consuming Disk Space

One of the most useful Linux storage troubleshooting techniques is checking for deleted files still held open by processes.

A process can continue holding an open file descriptor after its directory entry has been removed.

Check:

sudo lsof +L1

You might see:

application  1234  user  5w  REG ... /var/log/app.log (deleted)

The filename has been deleted, but its storage can remain allocated until the process closes the descriptor.

This can explain situations where:

df → filesystem is full
du → cannot account for all used space

Do not immediately kill a production process simply because it holds a deleted file. Determine the affected service and choose an appropriate operational response.

45. Linux Filesystem Troubleshooting Workflow

When a server reports a storage problem, use a structured process.

First check capacity:

df -h

Then check inodes:

df -i

Identify mounted filesystems:

findmnt

Inspect block devices:

lsblk -f

Find large top-level directories without crossing filesystem boundaries:

sudo du -xhd1 /

Search for very large files:

sudo find / -xdev -type f -size +1G -ls

Check deleted-open files:

sudo lsof +L1

Inspect important errors:

journalctl -p err

Check failed services:

systemctl --failed

This approach is considerably safer than randomly deleting files until disk usage decreases.

46. Common Linux Filesystem Problems

Disk Is Full

Possible causes include:

• Large logs
• Backups
• Database growth
• Application data
• Package caches
• Container images
• Temporary files
• Deleted-open files

Start with:

df -h

and then investigate the responsible directories.

Inodes Are Exhausted

Possible causes include:

• Millions of tiny files
• Cache directories
• Mail queues
• Application sessions
• Temporary files
• Container-related data

Check:

df -i

File Exists but Application Cannot Access It

Investigate:

ls -l
namei -l /path/to/file
getfacl /path/to/file

Also consider:

SELinux
AppArmor
ACLs
Parent-directory permissions
Mount options

Storage Disappeared After Reboot

Check:

findmnt
cat /etc/fstab
lsblk -f

Possible causes include an incorrect UUID, unavailable device, network-storage failure, bad fstab configuration, or boot dependency problem.

47. Using namei for Permission Troubleshooting

Suppose an application cannot access:

/var/www/site/uploads/file.jpg

Run:

namei -l /var/www/site/uploads/file.jpg

This helps inspect each component:

/
└── var
    └── www
        └── site
            └── uploads
                └── file.jpg

Access to the final file depends not only on the file’s permissions but also on access through the parent directories.

This makes namei extremely useful when ls -l file alone does not explain the problem.

48. Linux Filesystems and Web Servers

Web applications frequently use locations such as:

/var/www/

An application might have:

/var/www/example/
├── public/
├── config/
├── uploads/
└── logs/

Do not solve access problems by automatically running:

chmod -R 777 /var/www

Instead determine:

• Web-server user
• Application user
• Deployment user
• Which paths require writes
• Which configuration should remain restricted
• Where logs should be stored

Then assign ownership and permissions accordingly.

49. Containers and Linux Filesystems

Containers rely heavily on Linux filesystem concepts.

A simplified model is:

Container Process
       ↓
Container Root Filesystem
       ↓
Layered / Overlay Storage
       ↓
Host Kernel
       ↓
Host Storage

Persistent volumes provide a way to separate important application data from the lifecycle of a container’s writable layer.

The official Docker documentation explains Docker storage, volumes, bind mounts, and container filesystems in greater detail.

Understanding the host filesystem is therefore an important prerequisite for reliable container administration.

50. Virtual Machines and Filesystems

Virtual machines add additional layers:

Application
    ↓
Guest Filesystem
    ↓
Virtual Disk
    ↓
Hypervisor
    ↓
Host / Storage Platform
    ↓
Physical or Cloud Storage

A Linux VM might see:

/dev/nvme0n1

while the virtual disk itself is represented differently by the virtualization platform.

This is one reason storage-performance problems can become complex in virtualized infrastructure.

The Virtualization Explained guide covers the relationship between virtual machines, hypervisors, storage, and networking.

51. Linux Filesystem Performance

Filesystem administration is not only about available capacity.

Important storage metrics include:

IOPS
Throughput
Latency
Queue depth
Read/write ratio
Random vs sequential I/O

A database workload may prioritize latency and IOPS.

Large sequential data processing may care more about throughput.

Therefore:

High capacity ≠ high performance

and:

High throughput ≠ low latency

Storage must be evaluated according to the workload.

52. Monitoring Linux Storage

Useful commands can include:

df -h
df -i
lsblk
findmnt
vmstat
iostat

Depending on installed tools, utilities such as:

iotop
pidstat

can help identify processes responsible for I/O activity.

For networking-related server diagnostics, the Linux Network Tools Guide complements these storage utilities with tools for interfaces, routes, sockets, DNS, and packet troubleshooting.

A mature environment should ideally centralize important filesystem, disk, and service metrics rather than relying only on manual checks after an incident occurs.

53. Storage Monitoring Architecture

A simplified monitoring architecture looks like:

Linux Server
    │
    ├── Capacity metrics
    ├── Inode metrics
    ├── I/O metrics
    └── Logs
          │
          ▼
Monitoring Agent
          │
          ▼
Metrics / Logging Platform
          │
          ▼
Alerts
          │
          ▼
Administrator / SRE

Useful alerts can include:

• Filesystem capacity thresholds
• Inode exhaustion
• Abnormal I/O latency
• Device errors
• Mount failures
• Rapid storage growth
• Service failures caused by storage

The goal is to detect problems before the filesystem reaches a critical state.

54. Linux Filesystem Best Practices

Monitor capacity before filesystems reach 100%.

Monitor inode usage on workloads that generate large numbers of small files.

Understand what is stored under /var, especially logs, databases, caches, containers, and application state.

Avoid unnecessary 777 permissions and follow least privilege.

Back up critical configuration before modifying files such as:

/etc/fstab
/etc/ssh/*

Use stable identifiers for persistent storage when appropriate.

Test fstab changes before rebooting:

sudo mount -a

Do not delete unfamiliar files merely because a filesystem is full.

Check deleted-open files:

sudo lsof +L1

Finally, document the storage architecture:

Disk
 ↓
Partition
 ↓
LVM
 ↓
Filesystem
 ↓
Mount Point
 ↓
Application

A documented architecture is much easier to troubleshoot than an undocumented server assembled over time.

55. Production Linux Storage Architecture

A production server might use:

                Linux Application
                       │
                       ▼
                 /var/lib/app
                       │
                       ▼
                   XFS / ext4
                       │
                       ▼
              LVM Logical Volume
                       │
                       ▼
                  Volume Group
                       │
                ┌──────┴──────┐
                ▼             ▼
              Disk 1        Disk 2
                │             │
                └──────┬──────┘
                       ▼
               Cloud / SAN / RAID

The actual design depends on workload, performance, availability, recovery requirements, and infrastructure architecture.

Storage deserves the same design attention as CPU, memory, and networking.

56. Linux Filesystem Security Checklist

Before placing a Linux server into production, review:

• File ownership
• World-writable files and directories
• SUID/SGID usage
• ACLs
• /etc/fstab
• Sensitive-data encryption
• Backup protection
• Log retention
• Disk capacity monitoring
• Inode monitoring
• I/O monitoring
• SELinux or AppArmor status
• Application-directory permissions
• Recovery procedures

Filesystem security should be integrated into the overall server-hardening strategy rather than treated as a separate task.

57. Essential Linux Filesystem Commands

These commands form an effective basic toolkit for Linux filesystem administration.

58. Practical Linux Storage Investigation

Imagine an application reports:

No space left on device

Do not immediately delete files.

Start with:

df -h

Then:

df -i

If inode usage is normal, investigate directory usage:

sudo du -xhd1 /

Then narrow the search:

sudo du -xhd1 /var
sudo du -xhd1 /home
sudo du -xhd1 /opt

Find large files:

sudo find /var -type f -size +1G -ls

Check deleted-open files:

sudo lsof +L1

Then answer:

Why did storage usage increase?
Which process created the data?
Is the growth expected?
Can data be rotated or archived?
Is retention configured correctly?
Does the filesystem need expansion?

Only after understanding the cause should corrective action be taken.

59. A Useful Linux Filesystem Mental Model

Think of Linux storage like this:

                    Linux
                      │
              ┌───────┴───────┐
              │               │
        Directory Tree      Kernel
              │               │
              │         ┌─────┴─────┐
              │         │           │
          File Paths  Devices    Processes
              │         │           │
              └─────────┴───────────┘
                        │
                  Filesystem Layer
                        │
                ┌───────┴───────┐
                │               │
             Local           Network
            Storage          Storage
                │               │
                └───────┬───────┘
                        │
                   Applications

Once this mental model becomes intuitive, many Linux troubleshooting problems become easier to understand.

60. Linux Filesystems and DevOps

Modern DevOps workflows depend heavily on Linux filesystem concepts.

Configuration-management systems modify files under:

/etc/

CI/CD systems may deploy applications into locations such as:

/opt/
/srv/
/var/www/

Containers rely on layered filesystems and volumes.

Kubernetes workloads rely on storage abstractions and persistent volumes.

Infrastructure-as-Code systems can provision the storage resources underneath Linux hosts.

This connects filesystem knowledge directly to Infrastructure as Code and modern infrastructure engineering.

Linux filesystem knowledge is therefore not merely a traditional sysadmin skill—it is foundational to DevOps, cloud, containers, automation, security, and SRE.

61. Frequently Asked Questions

What is the Linux file system?

The Linux file system is the hierarchical structure and storage architecture Linux uses to organize files, directories, devices, mounted storage, metadata, permissions, and various kernel interfaces.

What is the root directory in Linux?

The root directory is:

/

It is the top of the Linux filesystem hierarchy.

Is /root the same as /?

No.

/ is the top of the filesystem hierarchy.

/root is normally the home directory of the root user.

What is /etc used for?

/etc primarily contains system-wide configuration files and configuration directories.

What is /var used for?

/var contains variable application and system data such as logs, caches, application state, queues, and other data that changes during normal operation.

What is /proc?

/proc is a virtual filesystem exposing process and kernel information.

What is /sys?

/sys exposes kernel-oriented information about devices, drivers, buses, and other system objects.

What is a mount point in Linux?

A mount point is a directory through which a filesystem becomes accessible within the Linux directory hierarchy.

What is the difference between df and du?

df reports filesystem-level capacity and usage. du estimates the space consumed by files and directories.

Why can df and du show different disk usage?

One possible cause is a deleted file that remains open by a running process. Filesystem accounting can continue to include the allocated blocks even though the deleted filename is no longer visible to normal directory scans.

Check with:

sudo lsof +L1

Can Linux run out of inodes while disk space is available?

Yes. A filesystem containing huge numbers of small files can exhaust its available inodes before consuming all available storage capacity.

Check with:

df -i

What is LVM?

LVM stands for Logical Volume Manager. It introduces an abstraction layer using physical volumes, volume groups, and logical volumes, allowing administrators to manage storage more flexibly.

What filesystem should I use on Linux?

There is no universal answer. ext4, XFS, Btrfs, and other filesystems have different features, operational characteristics, and distribution support. Choose according to workload and supported administration practices.

Why is chmod 777 dangerous?

It grants read, write, and execute permissions very broadly and can expose files or directories to unnecessary modification or execution. Assign only the permissions required by the intended users and services.

What commands should I use when a Linux disk is full?

A useful starting sequence is:

df -h
df -i
findmnt
lsblk -f
sudo du -xhd1 /
sudo lsof +L1

Then investigate the specific filesystem and application responsible for the growth.

62. Final Linux Filesystem Checklist

For everyday administration, remember:

pwd
ls -lah
df -h
df -i
du -sh
lsblk -f
findmnt
blkid
mount
umount
find
grep
stat
namei
getfacl
chmod
chown
lsof

For production storage troubleshooting, a useful starting workflow is:

df -h
df -i
lsblk -f
findmnt
sudo du -xhd1 /
sudo lsof +L1
journalctl -p err
systemctl --failed

The most important principle is:

Understand the storage hierarchy before changing it.

A Linux server is not simply a collection of files. Directories, permissions, processes, filesystems, block devices, mount points, applications, networking, and security controls interact continuously.

Conclusion

The Linux file system is one of the fundamental building blocks of Linux administration.

Once you understand the purpose of:

/
├── /etc
├── /home
├── /var
├── /usr
├── /boot
├── /dev
├── /proc
├── /sys
├── /run
└── /tmp

and how these locations interact with:

Permissions
Ownership
ACLs
Mounts
Filesystems
Inodes
LVM
Storage Devices
Processes
Security Controls

you have a much stronger foundation for managing real Linux infrastructure.

Filesystem knowledge also connects directly to networking, virtualization, cloud infrastructure, containers, DevOps, observability, and cybersecurity.

Continue developing those skills with the Linux Server Administration Guide, use the Linux Network Tools Guide when troubleshooting connectivity, and study Virtualization Explained when working with virtual infrastructure.

A reliable Linux administrator does not simply memorize commands. The key is understanding the layers underneath those commands:

Application
     ↓
Directory / File
     ↓
Filesystem
     ↓
Mount Point
     ↓
Logical / Block Storage
     ↓
Physical, Virtual or Network Storage

Once those relationships are clear, diagnosing Linux filesystem problems becomes far more systematic.