A Linux administrator has to know more than how to create files. The system only becomes predictable when you understand where files are expected to live, how storage devices are attached to that namespace, and what happens when a filesystem is mounted or unavailable. Those skills sit directly inside the current LPIC-1 101-500<\/a> objectives, which cover disk layout, filesystem creation and integrity, mounting, and the Filesystem Hierarchy Standard.<\/p>\n The current LPIC-1 version is 5.0, using exams 101-500 and 102-500. That matters because filesystem questions are not isolated trivia: they connect installation choices, boot behavior, package management, permissions, recovery, and everyday troubleshooting. Readers who are new to the ecosystem can place these skills in the broader LPI certification<\/a> path, but the operational goal is straightforward: know what a path means, where its storage comes from, and how to prove the system is mounted the way you think it is.<\/p>\n Linux presents files through a single directory tree rooted at That separation is powerful. An administrator can mount a dedicated filesystem at A broad Linux learning foundation<\/a> becomes much stronger once paths and mounts are understood together rather than memorized as separate command lists.<\/p>\n The root filesystem is also a dependency of almost every other mount. If it is damaged or too full to support normal startup, the system may fail before secondary filesystems are available. For that reason, administrators usually reserve enough capacity for logs, package operations, temporary work, and recovery tasks rather than sizing The Filesystem Hierarchy Standard helps distributions and administrators agree on the role of important directories. Other paths are virtual views rather than ordinary persistent storage. Understanding these roles also makes Linux device management<\/a> easier because devices, kernel views, persistent configuration, and application data stop looking like unrelated pieces.<\/p>\n FHS familiarity also helps when investigating unfamiliar software. Configuration under A partition defines a region of a storage device; a filesystem defines how files and directories are organized within storage. Administrators often use tools such as The choice to split LPIC-1 expects candidates to reason about layout rather than simply repeat directory names. This is one place where adjacent Linux+ administration<\/a> knowledge can reinforce the same real-world habit: storage design should reflect workload behavior, recovery needs, and operational risk.<\/p>\n Modern storage stacks may add LVM, encryption, RAID, cloud block devices, or network storage between the physical device and the mounted filesystem. LPIC-1 does not require every enterprise storage technology, but the layered model remains useful: the mount point is the final presentation layer, while several abstractions can sit beneath it.<\/p>\n The Unmounting with Mount options can also change behavior. Read-only mounts, execution restrictions, user-mountable media, and filesystem-specific options affect what processes can do even when ordinary file permissions appear permissive. When access behaves unexpectedly, checking the active mount options is part of proving the real security and operational state.<\/p>\n A manual mount disappears after reboot. Persistent local and network mounts are normally defined in Using UUIDs or stable labels is usually safer than depending on volatile device names such as This is where filesystem knowledge intersects with boot operations. A good understanding of Linux boot administration<\/a> helps explain why storage needed early in startup must be defined and tested carefully rather than treated as a post-login convenience.<\/p>\n Filesystems also track metadata structures such as inodes. A filesystem can have free data blocks but be unable to create more files if its inode supply is exhausted. Workloads that create millions of tiny files can hit that limit long before raw capacity is full. Administrators therefore monitor both space and inode consumption when relevant.<\/p>\n Integrity tools depend on filesystem type. A hard link creates another directory entry that refers to the same inode within the same filesystem. A symbolic link is a distinct filesystem object that stores a target path. The practical consequences are important. Hard links cannot normally cross filesystems and continue to reference the same data even if one name is removed. Symbolic links can cross filesystems but can become broken if their target is moved or deleted.<\/p>\n Administrators use links to provide stable names, maintain compatibility, or separate versioned content from the path applications expect. But links can also complicate troubleshooting. A path may resolve through one or several symbolic links before reaching the actual file, and access checks apply along the path. Commands such as For LPIC-1, links belong in the same mental model as mounting: the visible pathname is an interface, and the underlying storage relationship may be different from what the path alone suggests.<\/p>\n When an application reports \u201cno space left,\u201d \u201cpermission denied,\u201d or \u201cfile not found,\u201d the fastest fix is not always the most obvious one. First verify the active mount, source device, filesystem type, capacity, inodes, and permissions. Then check whether a mount failed at boot, a device identifier changed, a network dependency is unavailable, or a process is holding deleted data open.<\/p>\n Operational troubleshooting benefits from treating storage as layers: device, partition or logical volume, filesystem, mount, directory permissions, and application behavior. A symptom can originate at any one of them. The same disciplined approach is central to Linux troubleshooting<\/a>, where verifying state is more reliable than guessing from an error message.<\/p>\n This also explains why snapshot and backup strategies should be separate from simple mounting. A mounted filesystem can be perfectly healthy and still contain accidentally deleted or corrupted application data. Availability of storage is not the same as recoverability of information.<\/p>\n The current 101-500 objectives cover disk layout, filesystem creation, mounting, integrity, permissions, links, and FHS locations. Exam questions can therefore combine concepts. A persistent mount may require the right identifier and A useful study routine is to build a small lab, create a filesystem on a disposable volume, mount it manually, identify it by UUID, add a safe persistent entry, verify it after reboot, create links, fill it with test files, and inspect the results with The Linux filesystem is one tree, not a collection of drive letters<\/h3>\n
\/<\/code>. Storage devices, partitions, logical volumes, network filesystems, and removable media become visible by being mounted somewhere inside that tree. This is a conceptual difference from operating systems that expose storage primarily as independent drive letters. A path such as \/home\/alex\/project<\/code> tells you where the object appears in the namespace, but it does not by itself tell you which physical device or remote server stores the bytes.<\/p>\n\/var<\/code>, place user data on another volume at \/home<\/code>, or attach a network share below an application directory without changing how applications reference paths. The same abstraction also creates a troubleshooting requirement: when disk usage, permissions, or performance look wrong, you must ask both \u201cwhat path is this?\u201d and \u201cwhat filesystem backs this path?\u201d<\/p>\n\/<\/code> only for the current application footprint. Growth patterns should be part of the design.<\/p>\nThe Filesystem Hierarchy Standard gives common locations a purpose<\/h3>\n
\/etc<\/code> is associated with host-specific configuration, \/var<\/code> with variable data such as logs and queues, \/home<\/code> with ordinary users’ home directories, and \/boot<\/code> with files needed during the boot process. \/usr<\/code> contains a large share of installed user-space programs and read-only data, while \/tmp<\/code> is used for temporary files.<\/p>\n\/proc<\/code> exposes process and kernel information, \/sys<\/code> exposes device and kernel object information, and \/dev<\/code> contains device nodes that represent hardware or pseudo-devices. These locations are valuable because the hierarchy communicates intent. If a third-party application stores rapidly changing logs under a static program directory, or if an administrator treats \/proc<\/code> like a normal disk-backed directory, the design is already fighting Linux conventions.<\/p>\n\/etc<\/code>, variable state under \/var<\/code>, locally installed content under \/usr\/local<\/code>, and administrative binaries in standard locations give clues about whether a file belongs to the operating system, a package, or a local customization. Those clues are valuable during upgrades and incident response.<\/p>\nPartitions and filesystems solve different problems<\/h3>\n
fdisk<\/code>, gdisk<\/code>, or parted<\/code> to manage partition tables, then create filesystems with the appropriate mkfs<\/code> utility. Swap is a separate use of storage and is prepared with tools such as mkswap<\/code>.<\/p>\n\/<\/code>, \/var<\/code>, \/home<\/code>, or \/boot<\/code> onto separate filesystems is architectural rather than cosmetic. A busy logging workload can fill \/var<\/code>; putting it on a separate filesystem can stop that growth from consuming every byte available to the root filesystem. A separate \/home<\/code> can simplify data retention during operating-system replacement. On the other hand, too many small fixed partitions can strand free space and create administrative overhead.<\/p>\nMounting connects a filesystem to the directory tree<\/h3>\n
mount<\/code> command attaches a filesystem to a mount point, which is an existing directory. After the mount succeeds, the files from the mounted filesystem appear at that path. Any files that had existed in the mount-point directory are temporarily hidden until the filesystem is unmounted; they are not deleted. That detail explains many confusing incidents where an administrator believes files \u201cdisappeared\u201d after attaching a volume.<\/p>\nlsblk<\/code> provides a useful view of block devices and their relationships, while blkid<\/code> can show filesystem types, UUIDs, and labels. findmnt<\/code> and the mount<\/code> command can show active mount relationships. Together, these commands help answer three different questions: what storage exists, what identity a filesystem has, and where that filesystem is currently attached.<\/p>\numount<\/code> requires the filesystem not to be busy. Open files, a process whose current directory is inside the mount, or active application access can block an unmount. A careful administrator investigates the consumer rather than forcing a detach and risking inconsistent application behavior.<\/p>\nPersistent mounts belong in deliberate boot configuration<\/h3>\n
\/etc\/fstab<\/code> or represented by equivalent systemd mount configuration. An fstab<\/code> entry identifies the source, target mount point, filesystem type, options, and dump\/fsck fields. Because a bad entry can delay or disrupt boot, changes should be tested before the next restart.<\/p>\n\/dev\/sdb1<\/code>. Hardware discovery order can change, virtual disks can be added, and storage can move between systems. A UUID follows the filesystem itself, which makes the intended source clearer. That does not eliminate all risk\u2014duplicated filesystems or cloned images can duplicate identifiers\u2014but it is more robust than assuming a device name will never shift.<\/p>\nCapacity, inodes, and integrity are different health signals<\/h3>\n
df<\/code> reports filesystem space usage, while du<\/code> measures space consumed by directory trees and files that are visible through a path. They can disagree for legitimate reasons. A deleted file may still consume space while a process keeps it open, or a mount can hide files beneath a mount point. Those cases are valuable clues rather than proof that one command is wrong.<\/p>\nfsck<\/code> and filesystem-specific utilities such as e2fsck<\/code> or xfs_repair<\/code> are used in different repair workflows. They should not be treated as generic commands to run casually on a mounted production filesystem. Diagnosis, backups, maintenance state, and filesystem-specific guidance matter.<\/p>\nLinks add another layer between path names and stored data<\/h3>\n
ls -l<\/code>, readlink<\/code>, and realpath<\/code> help reveal what a name actually references.<\/p>\nFilesystem troubleshooting starts by proving the layer that failed<\/h3>\n
LPIC-1 scenarios reward relationships, not directory memorization<\/h3>\n
\/etc\/fstab<\/code> syntax; a full filesystem may actually be an inode problem; a \u201cmissing\u201d file may sit beneath a newly mounted filesystem; or a path may be a symbolic link into another hierarchy.<\/p>\ndf<\/code>, du<\/code>, lsblk<\/code>, and findmnt<\/code>. That turns a list of utilities into a connected operational model.<\/p>\n