Directory Structure

• The Linux filesystem is like a vast universe governed by a strict hierarchical order, with everything originating from the root directory (/), which acts like the “Big Bang” or the “center of the universe.” Just as the universe expands into complex structures, the Linux root expands into many distinct “galaxies” — subdirectories — each serving specific roles and responsibilities.

• The / (root) directory is the origin of all files and directories, akin to the “cosmic singularity.”

• From /, branches various essential galaxies (directories), segregating system files, binaries, user data, configurations, logs, and runtime information.

• This structure is maintained according to the Filesystem Hierarchy Standard (FHS), guaranteeing consistency across Linux distributions.

• Think of each directory as a vital “domain” in the Linux OS cosmos handling a specialized function, from booting the system, running binaries, storing configurations, to managing user data.

Key Subdirectories under Root (/*/) Explained

graph TD
    Root[/\//]:::root
    Root --> Bin[/bin/]:::bin
    Root --> Sbin[/sbin/]:::sbin
    Root --> Etc[/etc/]:::etc
    Root --> Home[/home/]:::home
    Home --> User1[/home/user1/]:::user
    Home --> User2[/home/user2/]:::user
    Root --> RootUser[/root/]:::rootuser
    Root --> Lib[/lib/]:::lib
    Root --> Lib64[/lib64/]:::lib64
    Root --> Usr[/usr/]:::usr
    Usr --> UsrBin[/usr/bin/]:::usrbin
    Usr --> UsrLib[/usr/lib/]:::usrlib
    Root --> Var[/var/]:::var
    Var --> VarLog[/var/log/]:::varlog
    Var --> VarSpool[/var/spool/]:::varspool
    Root --> Tmp[/tmp/]:::tmp
    Root --> Boot[/boot/]:::boot
    Root --> Dev[/dev/]:::dev
    Root --> Proc[/proc/]:::proc
    Root --> Sys[/sys/]:::sys
    Root --> Media[/media/]:::media
    Root --> Mnt[/mnt/]:::mnt
    Root --> Opt[/opt/]:::opt
    Root --> Run[/run/]:::run
    Root --> Srv[/srv/]:::srv

classDef root fill:#f96,stroke:#333,stroke-width:2px,color:#000;
classDef bin fill:#6f9,stroke:#333,stroke-width:1.5px,color:#000;
classDef sbin fill:#9cf,stroke:#222,stroke-width:1.5px,color:#000;
classDef etc fill:#fc9,stroke:#333,stroke-width:1.5px,color:#000;
classDef home fill:#99f,stroke:#333,stroke-width:1.5px,color:#fff;
classDef user fill:#bbf,stroke:#222,stroke-width:1px,color:#000;
classDef rootuser fill:#f69,stroke:#333,stroke-width:2px,color:#000;
classDef lib fill:#cfc,stroke:#222,stroke-width:1.5px,color:#000;
classDef lib64 fill:#c9f,stroke:#333,stroke-width:1.5px,color:#000;
classDef usr fill:#ff9,stroke:#333,stroke-width:1.5px,color:#000;
classDef usrbin fill:#fcf,stroke:#333,stroke-width:1.5px,color:#000;
classDef usrlib fill:#cff,stroke:#222,stroke-width:1.5px,color:#000;
classDef var fill:#f99,stroke:#222,stroke-width:1.5px,color:#000;
classDef varlog fill:#fbb,stroke:#333,stroke-width:1.5px,color:#000;
classDef varspool fill:#fdd,stroke:#333,stroke-width:1.5px,color:#000;
classDef tmp fill:#ccf,stroke:#222,stroke-width:1.5px,color:#000;
classDef boot fill:#fc6,stroke:#333,stroke-width:1.5px,color:#000;
classDef dev fill:#6cf,stroke:#222,stroke-width:1.5px,color:#000;
classDef proc fill:#f9f,stroke:#222,stroke-width:1.5px,color:#000;
classDef sys fill:#6ff,stroke:#333,stroke-width:1.5px,color:#000;
classDef media fill:#99c,stroke:#222,stroke-width:1.5px,color:#000;
classDef mnt fill:#f96,stroke:#333,stroke-width:1.5px,color:#000;
classDef opt fill:#9f9,stroke:#222,stroke-width:1.5px,color:#000;
classDef run fill:#9cf,stroke:#333,stroke-width:1.5px,color:#000;
classDef srv fill:#fc9,stroke:#222,stroke-width:1.5px,color:#000;

/bin

graph TD
    Root[/\//]:::root
    Root --> Bin[/bin/]:::bin
    Root --> Sbin[/sbin/]:::sbin
    Root --> Usr[/usr/]:::usr
    Usr --> UsrBin[/usr/bin/]:::usrbin
    Usr --> UsrSbin[/usr/sbin/]:::usrsbin
    Usr --> UsrLocalSbin[/usr/local/sbin/]:::usrlocalsbin

    %% class Root,Bin,Sbin,Usr,UsrBin,UsrSbin,UsrLocalSbin root,bin,sbin,usr,usrbin,usrsbin,usrlocalsbin;
    classDef root fill:#f4a261,color:#000,stroke:#333,stroke-width:1px;
    classDef bin fill:#e76f51,color:#fff,stroke:#000,stroke-width:1.5px;
    classDef sbin fill:#457b9d,color:#fff,stroke:#000,stroke-width:1.5px;
    classDef usr fill:#2a9d8f,color:#fff,stroke:#000,stroke-width:1.5px;
    classDef usrbin fill:#264653,color:#fff,stroke:#000,stroke-width:1.5px;
    classDef usrsbin fill:#e9c46a,color:#000,stroke:#000,stroke-width:1.5px;
    classDef usrlocalsbin fill:#8ecae6,color:#000,stroke:#000,stroke-width:1.5px;

• Contains essential user binaries (commands needed for booting and running Linux or while rescue/repair operations: ls, cp, mv, etc.). Accessible by all users.
• Core reusable commands for daily Linux navigation and file operations.
• It holds essential commands that need to be available in single-user mode (like during system boot or rescue mode) and for all users for basic system navigation and manipulation of files.
• These binaries are statically linked in some distros to ensure availability in early boot stages.
• Commands in /bin are required before other filesystems have been mounted (e.g., /usr), so /bin contents must reside on the root filesystem.

Note

• The split between (/bin, /sbin, /usr) originally existed due to hardware and boot-time constraints on early UNIX systems, where /bin and /sbin needed to reside on faster, smaller disks and be available during early system state, while /usr and its binaries came from a separate disk mount.
• The binaries inside /bin are mostly compiled ELF executables but can also be shell scripts or links.
• It must contain essential user commands needed in single user mode and required for operating the system.
• No subdirectories usually exist inside /bin; it contains only files or symbolic links to commands.
• Scripts or binaries that do not need to exist at the earliest stages of boot typically reside in /usr/bin or other directories.
• Modern systems sometimes have /bin as a symbolic link to /usr/bin due to unification efforts for simplification.

Tip

• Use /usr/local/bin or user-specific ~/bin for custom, local, or experimental executables.
• Keep /bin lean, containing only critical binaries necessary for boot, repair, and basic user operation.
• Maintain backups and verify binaries’ integrity regularly.

Caution

• /bin must be protected with strict permissions to prevent malicious tampering, as compromised binaries here can lead to system breach.
• File integrity monitoring (FIM) tools are often configured to watch /bin to detect unauthorized changes.
• Creating directories or unauthorized files in /bin is suspicious and flagged as a security incident.
• Do not manually add non-essential binaries or directories inside /bin.
• Avoid modifying core commands unless you fully understand consequences.
• “No boot without /bin, no run without root commands.”
• “A system unbootable is one that lost its /bin.” — Underscoring /bin commands’ importance for boot sequences.

/sbin

graph TD
    Root[/\//]:::root
    Root --> Bin[/bin/]:::bin
    Root --> Sbin[/sbin/]:::sbin
    Root --> Usr[/usr/]:::usr
    Usr --> UsrBin[/usr/bin/]:::usrbin
    Usr --> UsrSbin[/usr/sbin/]:::usrsbin
    Usr --> UsrLocalSbin[/usr/local/sbin/]:::usrlocalsbin

    %% class Root,Bin,Sbin,Usr,UsrBin,UsrSbin,UsrLocalSbin root,bin,sbin,usr,usrbin,usrsbin,usrlocalsbin;
    classDef root fill:#f4a261,color:#000,stroke:#333,stroke-width:1px;
    classDef bin fill:#e76f51,color:#fff,stroke:#000,stroke-width:1.5px;
    classDef sbin fill:#457b9d,color:#fff,stroke:#000,stroke-width:1.5px;
    classDef usr fill:#2a9d8f,color:#fff,stroke:#000,stroke-width:1.5px;
    classDef usrbin fill:#264653,color:#fff,stroke:#000,stroke-width:1.5px;
    classDef usrsbin fill:#e9c46a,color:#000,stroke:#000,stroke-width:1.5px;
    classDef usrlocalsbin fill:#8ecae6,color:#000,stroke:#000,stroke-width:1.5px;

• System binaries mainly used by the root or administrator (shutdown, mkfs, iptables), usually requiring elevated (root) privileges. Normal users rarely access here.
• Crucial for system recovery and low-level hardware management; separate to enhance security.
• It is essential for system boot, configuration, repair, and hardware setup before /usr and other filesystems are mounted.
• It may also host scripts (e.g., ifup, ifdown) and daemons used for system-level operations.

Note

• Files have restricted permissions and are generally owned by root.
• Filesystem Hierarchy Standard: /sbin should only contain binaries essential for booting, restoring, recovering, and/or repairing the system, beyond /bin.
• /sbin is primarily for the system administrator and is not typically included in regular users’ PATH environments—unless they use sudo or su for privilege escalation.
• Its contents are typically symlinked to /usr/sbin on modern distributions (usr merge).

Tip

Best Practices:

• Lean and secure: Only essential system binaries should reside in /sbin.
• No local scripts: Place custom admin tools in /usr/local/sbin.
• Regular audits: Hash and monitor /sbin binaries to catch unauthorized changes.
• Permissions: Ensure only root can write to /sbin; ordinary users can read/execute most binaries, but PATH exclusions limit accidental use.

Caution

• Integrity of /sbin binaries must be monitored—a compromise here risks system boot, repair, and core infrastructure.
• Avoid setting SUID/SGID bits unless strictly required.
• Only use trusted package managers to alter contents. Never add user scripts here unless managing system-wide admin utilities.
• Monitor for unauthorized changes using file integrity tools (AIDE, Tripwire) and restrict access to these binaries.
• Disable or lock login for default system accounts (bin, daemon, etc.) using /sbin/nologin or similar techniques.

/etc

graph TD
    Root[/\//]:::root
    Root --> Etc[/etc/]:::etc

    Etc --> Passwd[passwd]:::file
    Etc --> Shadow[shadow]:::securefile
    Etc --> Group[group]:::file
    Etc --> Gshadow[gshadow]:::securefile
    Etc --> Fstab[fstab]:::file
    Etc --> Sudoers[sudoers]:::securefile
    Etc --> Hosts[hosts]:::file
    Etc --> Resolv[resolv.conf]:::file
    Etc --> Network[network/]:::dir
    Etc --> Netplan[netplan/]:::dir
    Etc --> Crontab[crontab]:::file
    Etc --> CronD[cron.d/]:::dir
    Etc --> Systemd[systemd/]:::dir
    Etc --> Services[services]:::file
    Etc --> Sysctl[sysctl.conf]:::file
    Etc --> SSH[ssh/]:::dir
    Etc --> PAM[pam.d/]:::dir
    Etc --> Modprobe[modprobe.d/]:::dir
    Etc --> Sysconfig[sysconfig/]:::dir
    Etc --> Environment[environment]:::file
    Etc --> RcLocal[rc.local]:::file
    Etc --> X11[X11/]:::dir
    Etc --> Udev[udev/]:::dir
    Etc --> Security[security/]:::dir
    Etc --> Alternatives[alternatives/]:::dir
    Etc --> Profile[profile]:::file
    Etc --> Bashrc[bash.bashrc]:::file
    Etc --> Inputrc[inputrc]:::file
    Etc --> Locale[locale.conf]:::file
    Etc --> Issue[issue]:::file
    Etc --> Motd[motd]:::file
    Etc --> HostsAllowed[hosts.allow]:::securefile
    Etc --> HostsDenied[hosts.deny]:::securefile
    Etc --> LDAP[ldap.conf]:::file
    Etc --> Syslog[rsyslog.conf]:::file
    Etc --> LoginDefs[login.defs]:::file
    Etc --> ProfileD[profile.d/]:::dir
    Etc --> EnvironmentD[environment.d/]:::dir
    Etc --> PAMLimits[pam_limits.conf]:::file

    classDef root fill:#f4a261,color:#000,stroke:#333,stroke-width:2px;
    classDef etc fill:#264653,color:#fff,stroke:#333,stroke-width:2px;
    classDef dir fill:#2a9d8f,color:#fff,stroke:#222,stroke-width:1.5px;
    classDef file fill:#e76f51,color:#fff,stroke:#222,stroke-width:1.5px;
    classDef securefile fill:#9c2a2a,color:#fff,stroke:#222,stroke-width:1.5px;

• Configuration files for system-wide settings (e.g., network, user info, services).
• Contains config files necessary to customize system behavior.
• Mostly text-based files edited manually; critical for automated configuration management.

Note

• “Everything in Linux is a file, but /etc is where files decide how the universe works.”
• In the Filesystem Hierarchy Standard (FHS), /etc must contain host-specific configuration files, never binaries. Scripts found here (e.g., /etc/rc.local) are for boot or config purposes only.
• Configs in /etc are machine-specific—unlike /usr/share or /usr/local, which are read-only or shareable across systems.
• d-style directories like /etc/sudoers.d/, /etc/systemd/system/, /etc/cron.d/ allow easier config extension without modifying main files, facilitating package management and automation.

Tip

Best Practices:

• Regularly back up /etc and track with version control tools (like etckeeper).
• Backup /etc before large upgrades or configuration changes.
• Version control /etc using Git or etckeeper for rollback and audit history.
• Apply the principle of least privilege in all /etc configurations.
• Organize service configs into .d directories for cleaner upgrades and automation.

Caution

• Files like /etc/passwd and especially /etc/shadow must be tightly protected, with strict file permissions:
  • /etc/passwd: -rw-r--r-- 1 root root
  • /etc/shadow: -rw-r----- 1 root shadow
  • Ownership and permissions must always be audited; use chmod and chown to set.

/home

graph TD
    Home[/home/]:::home
    Home --> User1[/home/alice/]:::user
    Home --> User2[/home/bob/]:::user

    User1 --> Bashrc[.bashrc]:::dotfile
    User1 --> Profile[.profile]:::dotfile
    User1 --> SSH[.ssh/]:::dotdir
    User1 --> Documents[Documents/]:::dir
    User1 --> Downloads[Downloads/]:::dir
    User1 --> Config[.config/]:::dotdir
    User1 --> Cache[.cache/]:::dotdir

    classDef home fill:#2a9d8f,color:#fff,stroke:#333,stroke-width:2px;
    classDef user fill:#e76f51,color:#fff,stroke:#333,stroke-width:2px;
    classDef dotfile fill:#9c2a2a,color:#fff,stroke:#333,stroke-width:1.5px;
    classDef dotdir fill:#bb4444,color:#fff,stroke:#222,stroke-width:1.5px;
    classDef dir fill:#264653,color:#fff,stroke:#222,stroke-width:1.5px;

• In /home, privacy is paramount; permissions are your shield.
• The /home directory in Linux is the cornerstone of user personal workspaces. It holds user-specific files, configurations, and data essential for multi-user management.
• Each user gets a subdirectory (/home/USERNAME)
• Each user stores their work and preferences here.
• Users’ dotfiles and settings stored here impact the interactive shell and user environment. Purpose and Significance:
• Isolation: Separates personal files from system files, enabling independent user environments.
• Security: Permissions on /home subdirectories restrict access so one user cannot access another’s personal files without authorization.
• Portability: User data can be backed up or migrated independently from the system.
• Customization: Users configure their environment here, making /home a key piece in user experience and productivity.

Note

• The user’s home directory is the working environment for shells, GUIs, and applications. User Permission and Ownership
• Each user owns their home directory with rwx------ permission typical, restricting access.
• chmod and chown commands allow adjusting permissions and ownership.
• Root user can access all /home directories, but best practices avoid unnecessary root access to user files.

Tip

Quota and Limits:

• System admins may enable disk quotas to limit space usage by individual users on /home.
• Monitoring disk space is critical for ensuring system stability.

Best Practices:

• Backup regularly: User data and dotfiles should be backed up often to prevent loss.
• Separate partition: /home should ideally reside on its own disk partition. This allows OS upgrades or reinstallations without losing personal data.
• Use version control: Dotfiles can be managed with Git to synchronize settings across machines.
• Respect privacy: Maintain correct permissions to prevent cross-user access.
• Cleanup caches: Cache directories (~/.cache) can grow large and be safely deleted to free up space.
• Use symbolic links: Users can link directories inside home (like Documents) to external storage for better space management. Advances Tips:
• Moving /home to a Network File System (NFS) for centralized user data in enterprises.
• Using /home with encrypted volumes (ecryptfs, LUKS).
• Automating dotfiles deployment with tools like chezmoi, dotbot, or custom scripts.

Caution

• Use encrypted home directories or full disk encryption for sensitive environments.
• Limit sudo/root access to reduce risks to user files.
• Monitor home directories for suspicious modifications, especially of dotfiles.

/root

graph TD
    RootDir[/\//]:::root
    RootDir --> RootHome[/root/]:::roothome
    RootHome --> Bashrc[.bashrc]:::dotfile
    RootHome --> Profile[.profile]:::dotfile
    RootHome --> SSH[.ssh/]:::dotdir
    RootHome --> Config[.config/]:::dotdir
    RootHome --> Scripts[scripts/]:::adminfile
    RootHome --> Logs[logs/]:::adminfile
    RootHome --> Vimrc[.vimrc]:::dotfile
    RootHome --> Local[.local/]:::dotdir

    classDef root fill:#f4a261,color:#000,stroke:#333,stroke-width:2px;
    classDef roothome fill:#e76f51,color:#fff,stroke:#333,stroke-width:2px;
    classDef dotfile fill:#9c2a2a,color:#fff,stroke:#333,stroke-width:1.5px;
    classDef dotdir fill:#bb4444,color:#fff,stroke:#222,stroke-width:1.5px;
    classDef adminfile fill:#457b9d,color:#fff,stroke:#222,stroke-width:1.5px;

• The /root directory in Linux is the private home directory for the superuser (root). It is distinct from the root directory /, serving specific purposes, strict conventions, and critical workflows for Linux system administration.
• The root user lands in /root when logging in—as a secure and isolated workspace for administrative tasks.

Note

• /root is intentionally separated from /home/root to reduce accidental access, preserve privacy, and prevent interference by non-admin users.
• Ordinary users cannot access /root without using sudo or direct root login; permissions are typically 700, owned solely by root.
• In system recovery (single-user mode, rescue shells), /root acts as a safe working area when /home or other partitions are unavailable.

Tip

Best Practices:

• Restrict logins: Avoid direct remote root login (disable in /etc/ssh/sshd_config); use sudo or su for privilege escalation, maintaining accountability.
• Permission hygiene: Keep permissions on /root and its contents to 700 (rwx------).
• Backup carefully: Only trusted admins should backup /root. Store cryptographic keys securely.
• Audit scripts/tools: Everything in /root should be trustworthy—malware here would have full control.
• Avoid clutter: Do not store non-essential files in /root; use /home/admin for personal work, preserve /root for sysadmin and emergency use.
• Separation from /: Never confuse /root (root’s home) with / (system root).

Caution

• /root is part of the system’s root filesystem, never symlinked or mounted from elsewhere to avoid rescue/boot failures.

/lib or /lib64

graph TD
    Root[/\//]:::root
    Root --> Lib[/lib/]:::lib
    Root --> Lib64[/lib64/]:::lib64
    Root --> Modules[lib/modules/]:::modules

    Lib --> Libc[libc.so.6]:::so
    Lib --> Loader[ld-linux.so.2]:::so
    Lib64 --> Loader64[ld-linux-x86-64.so.2]:::so
    Lib64 --> Libc64[libc.so.6]:::so
    Modules --> KernelDir[5.15.0-xyz/]:::modules
    KernelDir --> NetDrv[net/]:::modules
    KernelDir --> FsDrv[fs/]:::modules

    classDef root fill:#f4a261,color:#000,stroke:#333,stroke-width:2px;
    classDef lib fill:#2684A9,color:#fff,stroke:#333,stroke-width:2px;
    classDef lib64 fill:#48416A,color:#fff,stroke:#222,stroke-width:2px;
    classDef modules fill:#8ecae6,color:#000,stroke:#333,stroke-width:2px;
    classDef so fill:#e76f51,color:#fff,stroke:#222,stroke-width:1.5px;

• Essential for executing commands and programs.
• /lib: Contains shared libraries (dynamic libraries, .so files) and kernel modules required at boot and by binaries in /bin and /sbin.
• /lib64: Stores the 64-bit versions of those libraries for 64-bit architectures. On 32-bit systems or legacy setups, this might not exist; on multilib systems, both directories allow running binaries of either architecture (32/64-bit).

What’s in /lib and /lib64?

• Shared libraries: For example, libc.so.6 (the C runtime library), SSL/TLS libraries, compression libraries, and system-level functionality libraries required for minimal system operation and recovery.
• Kernel modules: /lib/modules/$(uname -r)/ houses all loadable kernel drivers and modules for the currently installed kernels.
• Dynamic linker/loader: ld-linux.so.*—required by all dynamically linked ELF executables to start up and find their library dependencies.

Note

• Libraries are located via /etc/ld.so.conf and cached by ldconfig.
• Some system disaster recovery plans include backing up /lib or more often just /lib/modules. If the directory is missing or altered, boot and repair become impossible.
• Library files are upgraded only via trusted system package managers (e.g., apt, yum), not by copying files manually.

Tip

Best Practices and Tips

• Only root should have write access to /lib and /lib64. Ordinary users can only read.
• Never place custom or application-level libraries in /lib or /lib64; use /usr/lib, /usr/local/lib, or /opt/lib for those.
• Only install signed, official modules via your distro’s package manager.
• After package or kernel upgrades, always run ldconfig to refresh the shared library cache.
• For troubleshooting or system recovery, always ensure /lib and /lib64 are on the root filesystem—never on a separate mount!
• Use ldd <binary> to view what shared libraries an executable links against.

Caution

• The dynamic loader (ld-linux.so.*) finds and loads the required libraries—if these files are missing or corrupted, the entire system may fail to boot.

/usr

• User-related programs and data; contains /usr/bin, /usr/lib, /usr/share.
• Contains software installed for everyday use that doesn’t need root.
• Large directory with executables, libraries, docs; often mounted on a separate partition.

/var

• Variable data like logs (/var/log), mail, spool files, and caches.
• Stores files that grow/change over time.
• Crucial for system monitoring; logs help with debugging and security forensics.

/tmp

• Temporary files, cleared on reboot.
• Safe space for short-lived files.
• Sometimes used by developers for builds/scripts; permissions usually 1777 (sticky bit). See Sticky bits at 🌐

/boot

• Contains bootloader files, Linux kernel images.
• Needed during system startup.
• Kernel upgrades and bootloader configs like GRUB live here; sensitive to corruption.

/dev

• Device files representing hardware like disks (/dev/sda), terminals.
• Interface to hardware devices via file abstraction.
• Vital for interacting with hardware; dynamically populated via udev.

/proc

• Virtual filesystem exposing kernel and process information (/proc/cpuinfo, /proc/PID/).
• Read-only pseudo-files providing live system info.
• Useful for debugging and system stats; changes in real-time.

/sys

• Another virtual filesystem exposing device and kernel info, newer than /proc.
• Used by system tools and device managers to interact with hardware state.
• Integral in modern Linux for device configuration and kernel transparency.

/media

• Mount points for removable media like USB drives, CDs.
• Automatically mounted devices appear here.
• Typically managed by desktop environments automatically.

/mnt

• Temporary mount points for manually mounted filesystems.
• You manually mount drives here for temporary access.
• Traditionally used for system admin tasks and troubleshooting mounts.

/opt

• Optional/add-on software packages outside standard package management.
• Location for 3rd party or custom installed apps.
• Useful for large, self-contained applications or proprietary software.

/run

• Runtime data for processes started since boot (like PID files).
• Temporary runtime state storage.
• A tmpfs mounted early in boot; ephemeral and reset at reboot.

/srv

• Data served by system services (web servers, FTP).
• Where service-specific data resides.
• Helps isolate data for networked services and daemons.

Tip

Tilde Expansion (~)

• The tilde (~) symbol in Linux is a shell feature called “tilde expansion” that represents the home directory of a user. Specifically:
  • ~ alone denotes the current user’s home directory. If your username is USER and your home directory is /home/USER, then ~ is equivalent to /home/USER or $HOME.
  • ~/ represents paths relative to the current user’s home directory. For instance, ~/Documents points to /home/USER/Documents if the current user is USER.
  • ~USERNAME refers to the home directory of the specified user. So ~USER would expand to /home/USER if that user exists.
• This is a feature specific to shells like Bash, not the operating system itself. It’s a convenient shortcut for referencing home directories anywhere in the filesystem hierarchy.

Note

• The Linux filesystem hierarchy standard (FHS) ensures that software and system components are uniformly located across distributions, easing administration and scripting.
• /proc and /sys are virtual filesystems created on the fly, providing a dynamic window into the kernel and hardware — they do not occupy disk space.
• The /root directory is the home of the root user, not to be confused with / which is the root of the entire filesystem.
• Linux supports mounting different filesystems at any directory, allowing expansive and customizable system structures.

Tip

• “A directory is just a special file.” — Directories contain references to other file/inode metadata, forming the hierarchical structure.