Blog

On Linux, / is the starting point for nearly every file you use. A project folder in /home, a command in /usr/bin, a log in /var/log, and even a removable drive all appear somewhere beneath this single root. This unified layout differs from the drive-letter model used by many other operating systems.

The filesystem tree broadly follows the Filesystem Hierarchy Standard (FHS). Distributions differ in some details, but the main directories have stable roles. Knowing what belongs where makes shell work less confusing, supports safe troubleshooting, and helps you avoid putting files in system directories simply because they seem convenient.

One tree, many storage devices

A Linux filesystem is presented as one tree rooted at /, pronounced “root.” The root directory is not the same as the root user, even though both use the same word. The directory is the top of the hierarchy; the root user is an administrative account with broad privileges.

Physical disks, partitions, USB drives, network shares, and virtual filesystems can appear in this tree through mounting. For example, a separate disk might be mounted at /home, making its contents available there. On a desktop system, a USB drive may appear under /media/yourname/ or /run/media/yourname/, depending on the distribution and desktop environment.

A path therefore describes a location in the visible hierarchy, not necessarily a particular physical disk. Use df -h to see mounted filesystems and available space. findmnt gives a more direct view of what is mounted at each location.

Paths: absolute, relative, and special shorthand

A path identifies a file or directory. An absolute path starts with a slash and is interpreted from the root directory:

/home/alex/projects/demo/main.cpp
/etc/hosts

A relative path is interpreted from the current working directory. If the shell is currently in /home/alex/projects, then demo/main.cpp refers to the same file as the first absolute-path example.

• . means the current directory.
• .. means the parent directory.
• ~ expands to the current user’s home directory in most shells.
• - often means the previous directory in commands such as cd -.

Typical Linux filesystems are case-sensitive. Notes.txt and notes.txt can be different files. Names that begin with a period, such as .bashrc and .config, are hidden by default in directory listings. They are not protected or encrypted; the leading period is simply a naming convention.

The core directories and their jobs

Several directories appear on almost every Linux installation. Their names are short because they come from Unix conventions, but each has a distinct purpose.

/home: where personal work belongs

Each regular account normally has a directory under /home. It is the right place for source code, documents, downloads, user-level application settings, and SSH keys. A developer named Alex might work in /home/alex/projects, while graphical applications may keep settings in /home/alex/.config.

Keeping your work in your home directory has practical benefits. Package upgrades are less likely to overwrite it, backups can target it easily, and normal development tasks usually do not need administrator privileges. Avoid running editors, IDEs, or build tools with sudo in your home directory unless there is a clear reason. Doing so can create root-owned files and prevent you from editing them normally later.

/etc: configuration, not a workspace

The /etc directory stores host-specific configuration for the operating system and its services. It may contain account-related files, DNS resolver settings, network configuration, and settings for web servers or SSH. Some configurations are plain text, others use structured formats, and some are generated by management tools.

Before changing a configuration file, inspect it and make a backup with an obvious name. For example:

sudo cp /etc/example.conf /etc/example.conf.backup
sudoedit /etc/example.conf

sudoedit is often safer than opening a graphical editor as root. It lets you edit a temporary copy, then writes the result with the required privileges. On managed systems, check whether a file says it is generated automatically; manual changes may be replaced after an update or reboot.

/usr, /opt, and /usr/local

Despite its historical name, /usr is not a directory for individual users. It contains much of the software installed by the distribution. Executables often live in /usr/bin, shared libraries in /usr/lib, and architecture-independent shared data in /usr/share.

/usr/local is traditionally reserved for software installed locally by the system administrator rather than by the distribution’s package manager. /opt is often used for self-contained optional packages, especially third-party applications that maintain their own directory tree. The best choice depends on the distribution’s packaging conventions, but neither is the default location for a beginner’s personal code. Keep that in your home directory.

Directories that are not ordinary stored files

Some locations look like ordinary directories full of files, yet they are interfaces provided by the kernel. They can report changing system information, expose devices, or provide communication endpoints. Treat them with care.

• /dev contains device files. /dev/null discards output, and block-device entries can represent disks. Writing to a device path can affect real data, so avoid destructive experiments.
• /proc exposes process and kernel data. Files such as /proc/meminfo are generated dynamically rather than read from disk.
• /sys exposes information and controls related to devices and kernel subsystems. Some entries are writable and can change active system behavior.
• /run holds volatile runtime information. Its contents normally disappear after reboot.

These are often called pseudo-filesystems. They are useful for diagnosing systems you are authorized to inspect, but their apparent simplicity can be misleading. Writing text to a special file may change a kernel setting or interact with hardware rather than merely edit a document.

Temporary, variable, and recoverable data

/var holds data expected to change over time. Logs are commonly stored in /var/log, package-manager caches may be in /var/cache, and application state or spool queues may be kept elsewhere under /var. If disk space disappears unexpectedly on a server, checking /var is sensible. Do not delete files blindly, though: you could break a service or remove information needed for diagnosis.

/tmp is intended for temporary files. It is often writable by all users, with the sticky bit preventing users from deleting each other’s files. Temporary data may be cleaned during boot or by scheduled maintenance. Programs that need storage to survive a reboot should use a more suitable application-managed location—often /var/lib for system services or a user’s home directory for user applications.

Modern layout details: symbolic links and merged directories

On many current distributions, paths such as /bin, /sbin, and /lib are symbolic links to matching locations under /usr. This is called a merged-/usr layout. The older paths remain available for compatibility, so a command may show /bin even when the underlying target is /usr/bin.

Run ls -ld /bin /sbin /lib to check whether these entries are symbolic links on your system. A symbolic link points to another path; it is not a duplicate copy of the destination. readlink and realpath can help you inspect links when a configuration file or executable appears to be in an unexpected location.

Useful commands for safe exploration

Read-only inspection commands let you explore without changing the machine:

1. pwd prints the current directory.
2. ls -la lists entries, including hidden ones, with metadata.
3. tree -L 2, if installed, shows a limited directory tree.
4. du -sh ~/projects estimates the space used by a directory.
5. df -h reports free space on mounted filesystems.
6. stat filename shows detailed metadata for one file.
7. findmnt displays mount relationships.

Quote paths that contain spaces or shell-special characters: cd "My Project". Tab completion is safer than typing long system paths by hand because it reduces spelling mistakes and shows which names actually exist.

Ownership, permissions, and location are separate concepts

A file’s location does not decide who can read or modify it. Linux access decisions are based mainly on ownership, permission bits, access control lists where configured, and security mechanisms such as SELinux or AppArmor. A file under /home can be private, while a readable file under /etc may be visible to every local user.

This matters when you see “permission denied.” First verify the path with pwd and ls -l, then inspect the owner and mode instead of immediately reaching for sudo. For a deeper treatment of owners, groups, and safe permission changes, consult the blog’s practical guide to Linux file permissions, chmod, and ownership.

A small navigation exercise

Create a harmless practice tree in your own home directory, then inspect it:

mkdir -p ~/fs-practice/{notes,code}
printf 'first noten' > ~/fs-practice/notes/intro.txt
cd ~/fs-practice
pwd
ls -la
ls -la notes

The resulting intro.txt has the absolute path /home/your-user-name/fs-practice/notes/intro.txt. When your current directory is ~/fs-practice, its relative path is notes/intro.txt. When you are finished, remove only this practice directory with rm -r ~/fs-practice, and check the displayed path carefully before pressing Enter.