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

Core concepts6
Filesystem areas18
Inspection commands10
Main goalUnderstand before editing

Learning objectives

What you should understand before touching important files

01

Explain how the Linux filesystem is organized and why important paths matter during defensive review.

02

Recognize the difference between system configuration, user data, logs, temporary files, software, devices, and mounted filesystems.

03

Use safe inspection commands to identify what a file or directory is before changing it.

04

Interpret absolute paths, relative paths, hidden files, symbolic links, ownership, timestamps, and mount points.

05

Know which high-value Linux paths commonly contain account, service, authentication, networking, logging, package, and startup information.

06

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.

/etc

System 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.

/home

User 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.

/root

Root 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.

/var

Variable 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/log

Logs

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.

/usr

Installed 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/bin

Common 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/sbin

Administrative commands

Contains many system-administration utilities and service-related executables.

Defensive review

Administrative location alone does not make a file suspicious.

/bin and /sbin

Essential 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.

/opt

Optional 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.

/tmp

Temporary 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.

/run

Runtime 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.

/dev

Device 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.

/proc

Process 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.

/sys

Kernel 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.

/boot

Boot 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 /media

Mounted 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

pwd

Print the current working directory so you know what relative paths will refer to.

ls -la

List files including hidden entries, with ownership, permissions, size, and timestamps.

ls -ld /path

Inspect the directory or link itself instead of listing its contents.

file /path/to/item

Identify the apparent file type using content and metadata rather than relying only on the filename extension.

stat /path/to/item

Display detailed metadata such as size, ownership, permissions, inode information, and timestamps.

readlink -f /path/to/link

Resolve a symbolic link to its final target when possible.

findmnt

Display mounted filesystems and their mount points so you can understand what storage a path belongs to.

df -hT

Show mounted filesystem capacity and filesystem type in human-readable form.

du -sh /path

Estimate the total space used by a directory or file tree without changing it.

find /path -maxdepth 2 -type f -print 2>/dev/null

List 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

mtime

Usually 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

ctime

Reflects 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

atime

Can 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

btime

Some 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

01

Locate

Confirm the exact path and whether it is absolute or relative.

02

Classify

Determine whether the item is a regular file, directory, symbolic link, device, socket, mount point, or another object type.

03

Inspect metadata

Review ownership, permissions, size, timestamps, and link target.

04

Understand purpose

Connect the path to a user, package, service, application, startup mechanism, log source, or scenario requirement.

05

Preserve evidence

Capture relevant metadata, command output, and content before a destructive change if the item may matter to forensics.

06

Change narrowly

Modify only the confirmed problem rather than recursively changing an entire tree.

07

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.

01

Identify the system and confirm the current directory with cat /etc/os-release and pwd.

02

Inspect /home, /etc, /var/log, /tmp, and /opt using ls -ld and ls -la without changing anything.

03

Use file and stat on a fictional script named /tmp/maintenance-check.sh and record its type, owner, permissions, and timestamps.

04

Use readlink -f on /bin and compare the result with the expected merged-/usr layout.

05

Use findmnt and df -hT to identify which filesystems are mounted and where.

06

Classify the fictional script as Required, Unnecessary, Suspicious, or Investigate based on evidence. Do not delete it just because it is stored in /tmp.

07

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?

pwd

Show hidden files and ownership in the current directory.

ls -la

What type of object is this?

file /path/to/item

What are its detailed metadata and timestamps?

stat /path/to/item

Where does this symbolic link really point?

readlink -f /path/to/link

Is this directory on another mounted filesystem?

findmnt

How much space does this directory use?

du -sh /path

What files exist near this path without searching the whole system?

find /path -maxdepth 2 -type f -print 2>/dev/null

Lesson checklist

Before moving on

01

I can explain the difference between an absolute and relative path.

02

I know that hidden files are not automatically suspicious.

03

I check symbolic links before acting on the visible path.

04

I check mount points before assuming where data is stored.

05

I can identify high-value paths for users, sudo, SSH, networking, services, cron, and logs.

06

I use pwd, ls, file, stat, readlink, findmnt, df, du, and scoped find commands for inspection.

07

I understand that /proc, /sys, and /dev are not ordinary persistent data directories.

08

I preserve useful metadata and evidence before destructive remediation.

09

I avoid broad recursive chmod or chown changes without a known permission model.

10

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.