Linux · Lesson 02
Linux Filesystem & Important Paths
Learn how Linux organizes system configuration, user data, software, logs, devices, temporary files, mounted storage, and runtime state so you can investigate before you change.
Filesystem knowledge is foundational to every later Linux lesson. Users, permissions, SSH, services, packages, persistence, networking, and forensic evidence all depend on knowing what a path represents and what may depend on it.
Lesson Snapshot
Learning objectives
What you should understand before touching important files
Explain how the Linux filesystem is organized and why important paths matter during defensive review.
Recognize the difference between system configuration, user data, logs, temporary files, software, devices, and mounted filesystems.
Use safe inspection commands to identify what a file or directory is before changing it.
Interpret absolute paths, relative paths, hidden files, symbolic links, ownership, timestamps, and mount points.
Know which high-value Linux paths commonly contain account, service, authentication, networking, logging, package, and startup information.
Avoid destructive filesystem changes until purpose, dependency, ownership, and evidence value are understood.
Core idea
A path tells you where something lives, not whether it is safe
Security decisions require more than location. A file under /tmp can be legitimate, a file under /usr can be compromised, and a hidden file in a home directory can be completely normal. Combine path, metadata, purpose, dependencies, and evidence.
Safety boundary
Never repair a filesystem by guesswork
Deleting, moving, recursively changing ownership, or recursively changing permissions can break authentication, SSH, applications, package management, services, and evidence.
Filesystem fundamentals
Six ideas that make the directory tree easier to reason about
Everything begins at /
Linux uses one directory tree rooted at /. Drives, partitions, removable media, and network filesystems appear somewhere inside that tree instead of receiving Windows-style drive letters.
Paths describe location
An absolute path starts at /, such as /etc/ssh/sshd_config. A relative path starts from the current working directory, such as ./notes.txt or ../logs.
Names can be hidden
Files and directories beginning with a dot are normally hidden from a basic directory listing. Hidden does not mean malicious; many legitimate user and application settings use dotfiles.
Links can point elsewhere
A symbolic link is a reference to another path. Inspect where a link resolves before changing or deleting it because the visible path may not be the real file.
Mounts change what a path represents
A directory may be a mount point for another filesystem. Changes beneath it can affect a separate disk, partition, removable device, or network share.
Metadata is evidence
Ownership, permissions, size, timestamps, file type, link target, and filesystem location can help explain what a file is and how it is used.
Linux filesystem map
Know what the major paths are for
/Root
Top of the Linux filesystem tree. Every other path is below it.
Defensive review
Use it as the starting point for understanding where system, user, application, and mounted data live.
/etcSystem configuration
Stores many system-wide configuration files for accounts, services, networking, authentication, scheduled jobs, and applications.
Defensive review
High-value for defensive review, but changes here can affect the entire system. Inspect and preserve originals before editing.
/homeUser home directories
Usually stores normal users' personal files, shell configuration, application settings, SSH data, and other user-scoped content.
Defensive review
Compare directory ownership with authorized users and inspect hidden configuration only when relevant to the scenario.
/rootRoot user's home
Home directory for the root account.
Defensive review
Treat as highly privileged. Files here may contain administrative scripts, shell history, SSH material, or evidence.
/varVariable application and system data
Stores changing data such as logs, caches, queues, application state, databases, package information, and web content on many systems.
Defensive review
Important subdirectories include /var/log, /var/lib, /var/cache, and sometimes /var/www.
/var/logLogs
Contains many text logs and service-specific log directories, depending on the distribution and service.
Defensive review
Preserve relevant logs before remediation and correlate them with journalctl rather than assuming every event is stored here.
/usrInstalled user-space software and shared data
Contains many commands, libraries, documentation, and application resources installed by the operating system or package manager.
Defensive review
Unexpected files can matter, but package-managed content should not be modified casually.
/usr/binCommon commands
Contains many executable programs available to users and administrators.
Defensive review
If a process runs an unfamiliar executable here, identify its package and purpose before judging it.
/usr/sbinAdministrative commands
Contains many system-administration utilities and service-related executables.
Defensive review
Administrative location alone does not make a file suspicious.
/bin and /sbinEssential command paths
Traditionally contain essential commands. On modern Ubuntu-based systems they may be symbolic links into /usr.
Defensive review
Use readlink or ls -l to understand the actual layout instead of assuming every distribution stores binaries identically.
/optOptional or third-party software
Often used by manually installed or vendor software outside the normal package-managed hierarchy.
Defensive review
Useful place to investigate unfamiliar applications, but confirm legitimacy and dependencies before removal.
/tmpTemporary files
Shared temporary storage used by users, applications, installers, and scripts.
Defensive review
Temporary does not mean safe to delete blindly. Active applications may rely on files here, and artifacts may matter to forensics.
/runRuntime state
Stores volatile runtime information such as PID files, sockets, lock state, and other data created since boot.
Defensive review
Useful for understanding active services and runtime behavior. Much of it disappears after reboot.
/devDevice interfaces
Represents devices and pseudo-devices as filesystem objects.
Defensive review
Do not treat these like ordinary files. Writing to device paths can have direct system effects.
/procProcess and kernel information
Virtual filesystem exposing live process and kernel information.
Defensive review
Excellent for inspection. Content reflects current system state and is not ordinary persistent disk data.
/sysKernel and device information
Virtual filesystem exposing kernel objects, devices, drivers, and system attributes.
Defensive review
Primarily inspect unless you clearly understand the effect of writing to a sysfs control.
/bootBoot files
Contains bootloader and kernel-related files used to start the system.
Defensive review
High-impact area. Avoid changing boot content during routine hardening unless the scenario specifically requires it.
/mnt and /mediaMounted filesystems
Common locations for manually mounted filesystems and removable media.
Defensive review
Check what is mounted before assuming the files belong to the root filesystem.
High-value locations
Paths you will revisit throughout the Linux pathway
Accounts
User, group, password-hash metadata, and sudo configuration.
/etc/passwd/etc/shadow/etc/group/etc/gshadow/etc/sudoers/etc/sudoers.d/Authentication
Authentication modules, login defaults, and security-related configuration.
/etc/pam.d//etc/login.defs/etc/security/SSH
System-wide SSH server settings and user-level SSH keys or authorization data.
/etc/ssh/sshd_config/etc/ssh/sshd_config.d/~/.ssh/Networking
Hostname resolution, DNS state, network configuration, and NetworkManager configuration where used.
/etc/hosts/etc/resolv.conf/etc/netplan//etc/NetworkManager/Services
systemd unit files and local overrides. Exact vendor-unit location can vary across systems.
/etc/systemd/system//usr/lib/systemd/system//lib/systemd/system/Scheduled execution
System and user scheduled tasks. Exact spool paths can vary by distribution and configuration.
/etc/crontab/etc/cron.d//etc/cron.daily//etc/cron.hourly//var/spool/cron/Logs
Traditional text logs, authentication evidence, general system messages, and package-management history where present.
/var/log//var/log/auth.log/var/log/syslog/var/log/apt/Web content
Common web roots and web-service configuration when Apache or Nginx is installed.
/var/www//etc/apache2//etc/nginx/User startup
User shell and graphical startup behavior. Which files are used depends on shell and desktop environment.
~/.profile~/.bashrc~/.bash_profile~/.config/autostart/Inspection commands
Describe the filesystem before you modify it
pwdPrint the current working directory so you know what relative paths will refer to.
ls -laList files including hidden entries, with ownership, permissions, size, and timestamps.
ls -ld /pathInspect the directory or link itself instead of listing its contents.
file /path/to/itemIdentify the apparent file type using content and metadata rather than relying only on the filename extension.
stat /path/to/itemDisplay detailed metadata such as size, ownership, permissions, inode information, and timestamps.
readlink -f /path/to/linkResolve a symbolic link to its final target when possible.
findmntDisplay mounted filesystems and their mount points so you can understand what storage a path belongs to.
df -hTShow mounted filesystem capacity and filesystem type in human-readable form.
du -sh /pathEstimate the total space used by a directory or file tree without changing it.
find /path -maxdepth 2 -type f -print 2>/dev/nullList files within a limited search depth. Keep scope narrow so the command is useful and does not flood the terminal.
Keep searches scoped
A full-filesystem find can generate enormous output, cross mounted filesystems, hit permission errors, and waste competition time. Start with the smallest path and depth that can answer the question.
Evidence-based interpretation
Replace location-based guesses with filesystem reasoning
A file named update.sh appears in /tmp
Weak conclusion
It is in /tmp, so it must be malicious.
Better reasoning
Inspect owner, permissions, timestamps, content, process references, scheduled execution, and whether a legitimate installer or application created it.
/bin points to /usr/bin
Weak conclusion
The /bin directory was replaced.
Better reasoning
Modern Ubuntu-family systems commonly use a merged /usr layout. Confirm with ls -ld /bin and readlink rather than assuming compromise.
A hidden file exists in a user's home directory
Weak conclusion
Hidden means suspicious.
Better reasoning
Many legitimate shell and application settings are dotfiles. Identify the file's purpose, owner, content, and startup behavior.
An executable exists under /opt
Weak conclusion
Anything in /opt is unauthorized.
Better reasoning
Determine the software vendor, package or installation source, running processes, service dependencies, and scenario requirement first.
A directory contains root-owned files
Weak conclusion
The entire directory should belong to the user.
Better reasoning
System or application files may legitimately be root-owned. Compare the expected ownership model before running chown.
A path under /mnt contains unusual files
Weak conclusion
Those files are part of the Linux image.
Better reasoning
Check findmnt or mount first. The path may belong to another filesystem, removable device, or shared storage.
File timestamps
Useful evidence, not perfect truth
Modification time
mtimeUsually reflects when file content was last modified.
Copying, restoring, extracting, editing, or tooling can alter timestamps. Treat them as evidence that needs context.
Metadata change time
ctimeReflects when inode metadata such as permissions, ownership, or links changed.
ctime is not file creation time. It can change even when file contents do not.
Access time
atimeCan reflect when a file was accessed.
Mount options and filesystem behavior may reduce, delay, or suppress atime updates, so it is not universally reliable.
Birth/creation time
btimeSome filesystems and tools may expose file creation time.
Availability varies. Do not assume every Linux filesystem records or exposes it.
Safe filesystem workflow
Seven steps before a high-impact change
Locate
Confirm the exact path and whether it is absolute or relative.
Classify
Determine whether the item is a regular file, directory, symbolic link, device, socket, mount point, or another object type.
Inspect metadata
Review ownership, permissions, size, timestamps, and link target.
Understand purpose
Connect the path to a user, package, service, application, startup mechanism, log source, or scenario requirement.
Preserve evidence
Capture relevant metadata, command output, and content before a destructive change if the item may matter to forensics.
Change narrowly
Modify only the confirmed problem rather than recursively changing an entire tree.
Verify
Re-inspect the path and test the dependent user, service, or application.
High-risk shortcuts
Filesystem changes that deserve extra caution
Recursive chmod without a defined target model
Different files and directories often require different permissions. A blanket recursive mode can break executables, private keys, services, or application data.
Recursive chown across system directories
Package-managed files, service accounts, and privileged configuration may depend on specific ownership.
Deleting everything in /tmp because it is temporary
Active applications may use temporary files or sockets, and artifacts may still be relevant to investigation.
Editing /etc files without a backup or validation plan
A syntax error in authentication, networking, sudo, SSH, or service configuration can create immediate operational problems.
Following symbolic links without checking them
A command aimed at one visible path may affect data stored somewhere else.
Changing files under /proc, /sys, or /dev as if they were ordinary documents
These paths represent live kernel, process, hardware, or device interfaces and can have direct system effects.
Defensive lab
Map a fictional Linux filesystem safely
The lab uses inspection first. The goal is to understand what an item is and what evidence you still need, not to rush into deletion.
Identify the system and confirm the current directory with cat /etc/os-release and pwd.
Inspect /home, /etc, /var/log, /tmp, and /opt using ls -ld and ls -la without changing anything.
Use file and stat on a fictional script named /tmp/maintenance-check.sh and record its type, owner, permissions, and timestamps.
Use readlink -f on /bin and compare the result with the expected merged-/usr layout.
Use findmnt and df -hT to identify which filesystems are mounted and where.
Classify the fictional script as Required, Unnecessary, Suspicious, or Investigate based on evidence. Do not delete it just because it is stored in /tmp.
Document what additional evidence would be needed before remediation, such as cron references, process execution, package origin, or log events.
Command practice
Match the question to the inspection command
Where am I right now?
pwdShow hidden files and ownership in the current directory.
ls -laWhat type of object is this?
file /path/to/itemWhat are its detailed metadata and timestamps?
stat /path/to/itemWhere does this symbolic link really point?
readlink -f /path/to/linkIs this directory on another mounted filesystem?
findmntHow much space does this directory use?
du -sh /pathWhat files exist near this path without searching the whole system?
find /path -maxdepth 2 -type f -print 2>/dev/nullLesson checklist
Before moving on
I can explain the difference between an absolute and relative path.
I know that hidden files are not automatically suspicious.
I check symbolic links before acting on the visible path.
I check mount points before assuming where data is stored.
I can identify high-value paths for users, sudo, SSH, networking, services, cron, and logs.
I use pwd, ls, file, stat, readlink, findmnt, df, du, and scoped find commands for inspection.
I understand that /proc, /sys, and /dev are not ordinary persistent data directories.
I preserve useful metadata and evidence before destructive remediation.
I avoid broad recursive chmod or chown changes without a known permission model.
I verify dependent users, services, and applications after filesystem changes.
Reflection
Check your reasoning
Question 1
Why does Linux use one filesystem tree instead of drive letters?
Question 2
Why can a symbolic link make a filesystem change more dangerous than it first appears?
Question 3
Why should /tmp not be treated as a directory that is always safe to empty?
Question 4
What makes /etc especially important during defensive administration?
Question 5
Why can ownership or permission changes break a service even when the file still exists?
Question 6
How would you determine whether an unfamiliar file is required, suspicious, or simply unknown?
Carry this forward
The filesystem is the context for later Linux security work. Before changing an account file, SSH configuration, service, scheduled job, log, package, or permission, understand where it lives and what depends on it.