The Linux filesystem is organized around one directory tree, starting at /. Personal files, installed software, system settings, attached drives and information from the running kernel all appear somewhere beneath that starting point.
The names can look cryptic at first: /etc, /usr and /var do not offer much explanation on their own. Once you know what each directory holds, though, everyday tasks become easier. You can find an application’s settings, recognize which files need backing up and avoid treating a system directory as spare storage.
One Directory Tree, Not One Directory per Drive
The root directory, written as / and pronounced “slash,” is the top of the Linux directory structure. A path such as /home/alex/Documents/report.pdf starts there, passes through three directories and ends at a file.
This tree can stretch across several storage devices. Your operating system might live on one SSD, your home directory on another and a backup drive beneath a third directory. Linux joins these storage locations to the same tree through mounting. The Debian Reference section on Unix-like filesystems documents this relationship between the directory tree and mounted devices.
Three terms need separating. A directory holds names that refer to files and other directories. A filesystem, such as ext4 or Btrfs, provides the structures used to store and manage them. The directory hierarchy describes where those directories belong. Changing the underlying filesystem does not automatically change the familiar names beneath /.
Also, the root directory is not the root user’s home directory. / is the starting point for paths; /root is normally the administrator account’s personal directory.
How to Read Linux File Paths
An absolute path begins with / and identifies a location from the root directory. For example, /home/alex/Documents/report.pdf identifies the same location regardless of which directory you are currently viewing.
A relative path starts from your current directory. If you are already in /home/alex, the path Documents/report.pdf refers to that same document. From another directory, it refers somewhere else or may not exist.
Two short forms appear frequently: . means the current directory, and .. means its parent. In a typical shell, ~ expands to your home directory. It is shorthand interpreted by the shell, not another directory sitting beside /home.
Names on typical Linux filesystems are case sensitive, so Documents and documents can be different directories. Spaces are allowed in filenames, although they require care in terminal input. The guide to essential Linux terminal commands covers working with paths from the command line.
The Main Linux Directories and Their Roles
The Filesystem Hierarchy Standard sets out conventions for directory placement. Distributions can differ, but these names provide a useful working map.
| Directory | Main purpose |
|---|---|
/home |
Home directories for ordinary user accounts. |
/root |
The root account’s home directory. |
/etc |
System configuration. |
/usr |
Installed commands, libraries and shared software resources. |
/var |
Changing system data, including logs, caches and application state. |
/boot |
Files used during startup. |
/opt |
Additional application packages, often grouped by application or vendor. |
/srv |
Data provided by services on the system. |
/media |
Mount points for removable storage. |
/mnt |
A conventional location for temporary mounts. |
/tmp |
Temporary files. |
/run |
Runtime data associated with the current boot. |
/dev |
Device interfaces. |
/proc and /sys |
Interfaces to information and controls exposed by the kernel. |
These directories are not interchangeable. A large file beneath /var/lib may be valuable application data, while a similarly sized file beneath a cache directory may be replaceable. Location is a clue to purpose, not permission to delete.
Your Home Directory: Documents, Settings and Hidden Files
An ordinary user’s home directory is commonly located at /home/username. For an account named Alex, that might be /home/alex. Documents, downloads, photographs and project folders belong here rather than directly beneath /.
Home also contains application settings and data. Many of these names begin with a dot, which makes them hidden from ordinary directory listings and the default view in many file managers. Hidden does not mean protected or unimportant. It is a display convention, not a security feature.
The XDG Base Directory Specification defines common defaults: ~/.config for settings, ~/.local/share for user data, ~/.local/state for persistent state such as history, and ~/.cache for replaceable cached data. Applications can use different locations when the relevant environment variables are set.
Not every application follows these conventions. Some retain their own hidden directories directly inside your home directory. An unfamiliar dot directory is therefore not automatically leftover clutter.
Consider a text editor that keeps preferences in ~/.config and working state elsewhere. Backing up Documents alone would preserve your writing but could miss your editor setup. Before moving to another computer, check where the applications you depend on store their data.
Home directory permissions also vary between installations. Another local account may or may not be able to browse parts of your home directory. Do not assume that placing a file beneath /home makes it private.
Where Installed Software Lives
Linux applications do not necessarily sit inside one self-contained folder. A distribution package can place its executable in one directory, shared resources in another and configuration elsewhere. The package manager tracks those files as parts of the same installation.
Much of this software lives beneath /usr. Despite its name, this is not the place for your personal documents. /usr/bin contains commands and executables, /usr/share holds resources such as documentation and icons, and library directories provide code used by applications. Library paths vary with the distribution and processor architecture.
This spread is one reason to remove packaged software through its package manager rather than deleting whichever executable you find first. The guide to APT, DNF and Pacman explains how package management handles installation and removal.
Why /bin and /usr/bin may lead to the same place
On systems using a merged /usr layout, traditional directories such as /bin and /lib are symbolic links to locations beneath /usr. A symbolic link points to another path; it does not create a second copy of the target’s contents.
The UAPI Group’s Linux filesystem hierarchy document describes compatibility links used in modern layouts. Exact arrangements differ, including whether administrative commands share /usr/bin or remain under /usr/sbin. Do not remove these links because the directories appear duplicated.
For software installed locally by an administrator, /usr/local provides a separate hierarchy. Some additional applications use /opt, while user applications may store executable files beneath ~/.local/bin.
Installation formats introduce further differences. For those choices, see installing applications with native packages, Flatpak and Snap. The practical rule is to let the installation tool manage its own files.
Configuration in /etc, Changing Data in /var
/etc holds system configuration. Examples include /etc/hosts, which can define local hostname mappings, and /etc/fstab, which can describe filesystem mounts. Application and service settings often occupy subdirectories here.
The distinction between system and personal configuration matters. A change beneath /etc can affect the whole computer. A change to an application’s settings in your home directory normally applies to your account. When troubleshooting one user’s preferences, start with that user’s configuration rather than changing a system setting.
/var holds data that changes during normal operation. Its subdirectories separate different kinds of work: /var/log for logs, /var/cache for caches and /var/lib for persistent application or service state. /var/spool can hold queued work, such as print jobs.
“Variable” does not mean disposable. A database beneath /var/lib may hold the only copy of its records. Package management information can also live there. Deleting such files to free space may leave software broken even when its executable remains intact.
Logs need similar care. Some are readable text files; others require a dedicated viewer. On systems using systemd’s journal, troubleshooting with journalctl is more useful than opening journal storage files in a text editor.
/tmp, /var/tmp and /run Have Different Lifetimes
/tmp is scratch space, not a safe place for a document you intend to keep. Its contents may disappear at startup or through automatic cleanup. It may also use a memory-backed filesystem rather than persistent disk storage.
/var/tmp serves temporary work that needs to survive a reboot, although cleanup policies can still remove older files. /run serves a different purpose: it holds runtime information such as communication sockets and process-related files for the current boot. These distinctions appear in the systemd filesystem hierarchy manual.
A useful way to separate them is by purpose. A temporary working file belongs in temporary storage; a service’s live communication endpoint belongs in runtime storage; a saved document belongs in persistent personal storage.
Do not empty these directories indiscriminately while applications are running. A file can be temporary and still be needed right now. Prefer the application’s cleanup controls or the distribution’s maintenance tools over manual deletion.
Mount Points: Where Other Drives Join the Tree
A mount point is a directory at which another filesystem becomes accessible. If a backup drive is mounted at /media/alex/Backup, its files appear beneath that path. The mount does not copy the drive’s contents into the operating system’s filesystem.
Desktop environments often handle removable drives automatically, and the chosen path varies. /media is a conventional location for removable storage; /mnt is commonly used for mounts arranged by an administrator. Neither directory is itself a drive.
The same principle applies to internal storage. /home can be an ordinary directory within the root filesystem or the mount point for a separate filesystem. Its visible path need not reveal which arrangement is in use.
A separate home filesystem can make some reinstallations easier, but it is not a backup. Accidental deletion, drive failure and an incorrect formatting choice can still destroy the data. Anyone planning partitions should review the storage choices in the Linux installation guide before making changes.
Mounting also explains why a directory can suddenly show different contents. A mounted filesystem hides the directory’s previous contents until it is unmounted; it does not erase them. This matters when a drive fails to mount and an application writes into the underlying directory instead.
Windows storage can join this tree too. A Windows partition remains a separate filesystem even when Linux displays it beneath a normal-looking directory. The guide to dual booting Linux and Windows covers the broader setup considerations.
/dev, /proc and /sys Are Not Ordinary Storage
The phrase “everything is a file” is useful shorthand, but it can mislead. Linux exposes many interfaces through filesystem paths. Opening one does not necessarily mean reading a document stored on an SSD.
/dev contains device interfaces. A path such as /dev/nvme0n1 can represent a storage device, not a folder holding that device’s documents. Writing directly to a storage device can overwrite its contents. Device paths are not suitable targets for casual file editing.
/proc exposes information about processes and the running system. Numbered directories relate to process identifiers, while other entries provide system information or controls. The Linux kernel documentation for procfs describes both its information interfaces and writable runtime settings.
These entries can change as processes start and stop. They are not a collection of persistent documents, and copying them is not a substitute for backing up the system.
/sys exposes kernel objects and their attributes, including device-related information. Some attributes can be changed by writing to them, which can affect the running system. The kernel documentation for sysfs describes how those reads and writes connect to kernel operations.
For routine checks, start with tools designed for monitoring CPU, memory, disk and network usage. They present useful measurements without requiring you to interpret every virtual file yourself.
Why Some Directories Refuse Changes
Ordinary accounts generally cannot modify most operating system files. That separation helps prevent an application, or an accidental action, from damaging the installation.
A permission error is therefore not automatically a fault. Being able to read a file does not imply permission to edit it, and access to a directory depends on permissions along its path. A read only mount can prevent changes even when ownership appears correct.
Avoid responding by granting broad write access or changing ownership across a system directory. Work through Linux file permissions and ownership to identify the actual restriction. Administrative access should serve a defined task, not become the default mode for browsing files.
Use the Directory Structure to Make Better Decisions
You do not need to memorize every directory before using Linux. Start by identifying who owns the data, what creates it and whether it must survive a reboot or reinstall.
For personal work, use your home directory. When an application misbehaves for one account, check its user settings before changing system configuration. When storage fills up, identify the growing directory before deciding what can safely go.
Backups should reflect how you use the computer. Personal documents are an obvious starting point, but application data, hidden settings and locally managed service data may matter just as much. Backing up and restoring a Linux desktop covers turning those locations into a recovery plan.
Treat startup files beneath /boot with particular care. Remove obsolete kernels through supported package tools rather than deleting files by hand. If startup is already failing, use a structured process for recovering a Linux system that will not boot.
The directory tree becomes useful when it answers a practical question: is this a personal file, installed software, configuration, persistent state, temporary work or a live system interface? Establish that before editing or deleting anything, and the short directory names become much less mysterious.