Step 27. Exploring the Directory Structure — Putting the Linux Map in Your Hands

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★☆☆☆ | Estimated time: 3 hours

Prerequisites: You must have finished the Linux fundamentals from Steps 18–26 (commands, permissions, processes). You need an Ubuntu VM (or WSL Ubuntu).

• What you need: An Ubuntu terminal. Nothing new to install.
• Caution: This section’s practice is 100% read-only. You only look, with ls, cat, df, and du. There is no editing of files in system areas like /etc today.

People who have used Windows for a long time often feel its folder structure is arbitrary — programs live in both Program Files and AppData, and settings live in both the registry and ini files. Linux is different. There’s a standard layout chart decades old, so “configs go here, logs go here, commands go here” is a promise. In security work, the first thing you do when you connect to a server is figure out “what’s where” — today you’ll complete that map, and you’ll also meet /proc, the mysterious folder that exists without existing on disk.

1. Learning Objectives

By the end of this unit, you will be able to:

• Explain the roles of Linux’s top-level folders (/etc, /var, /bin, etc.)
• Look at any path and guess “this must be that kind of file”
• Explain that /proc is not on disk but a virtual folder the kernel generates in real time
• Check free disk space with df and per-folder sizes with du
• Confirm the design philosophy “in Linux, everything is a file” through the /proc hands-on work

2. Background Knowledge — Today’s Tools and Concepts

This section’s Tools at a Glance

2-1. A Single Root — A Tree Starting from /

Every path in Linux starts from one place: / (root). There’s no C: drive or D: drive like in Windows. Plug in a USB stick or attach another disk — everything enters somewhere as a branch of this one tree. That’s called a mount — “hanging it on the tree.”

A single tree means any file can be reached by following the path from /.

2-2. The Top-Level Folder Map — FHS

The name of this promise is the FHS (Filesystem Hierarchy Standard). The core folders:

Don’t try to memorize these. Walk through them with your hands today and they’ll stick naturally. One line to remember: “configs in /etc, logs in /var, my stuff in /home.”

2-3. /proc — A Living Virtual Folder

This is this section’s highlight. The files inside /proc are not stored anywhere on disk. The moment you run ls /proc, the kernel (the heart of the operating system) fabricates “the state at this very moment” on the spot, in the shape of files.

• Folders with numeric names: The PIDs of processes running right now (that number from Step 26!). /proc/652/ is the information folder for process PID 652.
• /proc/cpuinfo: CPU information. /proc/meminfo: memory information.

That’s why /proc files show a size of 0 in ls -l. Not because they’re empty, but because they’re “generated the moment you read them,” so their size can’t be known in advance. Read them with cat and the contents pour out. It’s the pinnacle of the philosophy “in Linux, everything is a file” — even the kernel’s inner thoughts are files.

3. Follow Along

Before you begin. Some directories expose kernel information rather than ordinary disk files. Paths and symlinks differ across distributions; many current Ubuntu systems merge /bin into /usr/bin.

3-1. Touring the Top-Level Folders

ls /

bin   dev  home  lib64  mnt  proc  run   srv  tmp  var
boot  etc  lib   media  opt  root  sbin  sys  usr

(Directory listings vary by installation. This WSL example also includes init, snap, lost+found, and bin.usr-is-merged. Compare the core directories with the map and record differences in your own environment.)

How to read it: The folders from the section 2-2 map are really there. Say each one’s role out loud as a guess, then check it against the map.

ls /etc | head -10

NetworkManager
PackageKit
X11
adduser.conf
alternatives
apache2
apparmor
apparmor.d
apport
apt

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: All configuration files or config folders. adduser.conf is the config for adduser, which we used to create accounts. Looking at the names, “ah, that’s that program’s config” starts to become visible.

3-2. Exploring /proc

ls /proc | head -6

1
114
115
183
...

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: The numeric names = the PIDs of processes alive right now. The world you saw with ps aux in Step 26 is spread out here in folder form.

cat /proc/cpuinfo | head -13

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 197
model name	: Intel(R) Core(TM) Ultra 7 255H
stepping	: 2
microcode	: 0xffffffff
cpu MHz		: 3686.397
cache size	: 24576 KB
...

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: This content didn’t exist a moment ago — the kernel produced it the instant cat read it.

Prediction: ls -l /proc/cpuinfo commonly reports a size of zero even though reading it returns information. procfs generates content on demand; the size field is not a reliable measure of the bytes a read will return.

cat /proc/meminfo | head -5

MemTotal:        7839388 kB
MemFree:         6374836 kB
MemAvailable:    7065700 kB
Buffers:           51784 kB
Cached:           769476 kB

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: Total memory, free memory, and practically available memory. This is where you look when a server is slow.

cat /proc/1/cmdline; echo

/sbin/init

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: PID 1 — the launch command of “the ancestor of all processes” from Step 26. (The trailing echo is just for a newline. cmdline has no newline at the end, so the prompt would otherwise stick to it.)

Why: Processes, hardware, and kernel state are all queried through plain “file reading.” Not a complicated API — cat is enough. That’s the Linux worldview.

3-3. Viewing Disk Capacity — df and du

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdd       1007G  2.6G  954G   1% /
...

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: df means “disk free.” The -h asks for human-friendly units (G, M). Reading the first live line: of 1007G total, 2.6G used, 954G available, 1% usage, mounted on /.

du -sh ~

8.4M	/root

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: du means “disk usage.” -s shows only the total, -h uses human units. ~ is shorthand for “my home folder.”

Why: df asks “how full is the whole disk,” du asks “how much does this folder eat.” In server operations, a full disk is a classic cause of outages, and these two commands are where diagnosis begins. Incidents where logs pile up until /var bursts are anything but rare.

3-4. Visiting /var, the Home of Logs

ls /var/log | head -12

README
alternatives.log
apt
auth.log
bootstrap.log
btmp
dist-upgrade
dmesg
...

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: The auth.log you met in Step 24 (the sudo and login record) lives here. This is where the system’s diaries gather.

sudo tail -5 /var/log/syslog

(Output omitted — you’ll see the five most recent lines of the system-wide log. Just soak in the atmosphere of what gets recorded. On newer environments without syslog, sudo journalctl -n 5 plays the same role.)

Why: The destination of the habit “when something goes wrong, read the logs” is exactly this folder. Put a star on it in your map.

3-5. A Command’s Real Address — which

which date ls grep bash

/usr/bin/date
/usr/bin/ls
/usr/bin/grep
/usr/bin/bash

Illustrative output. Values, wording, account names, and available fields vary by environment.

How to read it: The actual file locations of the commands you type every day. They show up like this because the map’s /bin is usually linked (symbolic link) to /usr/bin. You’ve confirmed the fact that “a command is, in the end, a file sitting somewhere.”

4. Missions & Exercises

Mission — Draw Your Linux’s Filesystem Map

1. Draw this section’s nine top-level folders as a tree diagram, add a one-line description to each, and save it as filesystem-map.txt
2. Create a process with sleep 300 &, then browse the /proc/PID/ folder with ls using the PID that appeared — confirm it’s “my process” with cat /proc/PID/cmdline; echo
3. Note the Use% from df -h / in a corner of your map, and also write down the three biggest things in your home using du -sh ~/* 2>/dev/null | sort -h | tail -3
4. Read two regular readable entries under /proc, such as version and uptime, and compare content with ls -l. Do not assume every proc entry reports size zero.
5. When done, clean up the sleep with kill, as you learned in Step 26

Exercises

Question 1. Using the FHS map, guess which folder each of these files would live in: ① the nginx web server’s configuration ② the system login record ③ the grep command’s executable ④ the temporary executable attackers love to drop secretly.

Question 2. /proc/cpuinfo shows 0 bytes in ls -l, yet cat reads content from it. Is it a broken file? Why does this happen?

Question 3. df -h and du -sh ~ are both “capacity” commands. What does each one measure, and in what order would you use them if you got a report that “the server died from disk shortage”?

Question 4. Linux has no drive letters like C: or D:. When you plug in a USB stick, how do its files enter the / tree? Name this mechanism.

nano filesystem-map.txt   # write it yourself, referring to the content below

/ (root — where everything begins)
├─ /etc   : configuration files (the document cabinet)
├─ /var   : logs and changing data (the diary) — /var/log is the home of logs
├─ /home  : user homes (everyone's own room)
├─ /bin, /sbin : command executables (the toolbox)
├─ /usr   : installed programs (the warehouse)
├─ /tmp   : temporary files (cleanup depends on policy)
├─ /proc  : virtual folder the kernel creates in real time (inner thoughts)
├─ /dev   : where devices are shown as files (connectors)
└─ /root  : root's home folder (the admin's office)

Disk status: / usage 1% (df -h, as verified 2026-09-09)

6. Common Pitfalls & Fixes

Wall 1. “The /proc file is 0 bytes, so why does content come out? Is it broken?”

Symptom: ls -l shows size 0, but cat reads content from it (reproduced exactly as-is live on 2026-09-09).
Cause: Not a malfunction — normal behavior of a virtual file. The kernel generates it at read time, so there’s no size in advance.
Fix: The rule for /proc and /sys files is “ignore the size and only view them with cat.” Opening them in nano or copying them with cp behaves awkwardly, so treat them as read-only.

Wall 2. “I edited a file in /etc but it won’t save”

Symptom: You opened a file inside /etc with nano and edited it, but saving gives Permission denied.
Cause: /etc is a system area, so regular users can only read. It’s a place that needs the “master key to the public facility” from Step 24.
Fix: Open it with sudo nano /etc/filename. But make it a habit to back up the original first with sudo cp filename filename.bak. A verified backup gives you a recovery option if the edit fails. (This section’s chapter scope ends at viewing.)

Wall 3. “The folder names all look alike and it’s confusing. /bin, /sbin, /usr/bin…”

Symptom: You’re confused about where commands live and why there are several similar folders.
Cause: For historical reasons, the layers overlap. The distinction is sbin for system administrators, /usr for installed programs — and modern Ubuntu links /bin to /usr/bin.
Fix: Don’t memorize it all now. which command tells you the real location (as in the subsection 3-5 illustrative example).

Wall 4. “I ran df -h and there’s a bunch of tmpfs entries. Do I have multiple disks?”

Symptom: The df output shows several tmpfs lines besides /dev/…
Cause: tmpfs is not a disk but a virtual filesystem created on memory. It’s for “fast temporary space,” like /dev/shm.
Fix: Just look at the lines starting with /dev — the real disks. The one mounted on / is your main disk.

Wall 5. “I went into a /proc/number folder and there’s a pile of files — no idea what to look at”

Symptom: You ran ls somewhere like /proc/1/ and dozens of files came out.
Cause: The entire state of one process is spread out as files. You don’t need to understand all of them.
Fix: At the beginner stage, look at three things: cmdline (what command started it), status (state summary), and cwd (current working folder — it’s a symbolic link, so view it with ls -l).

7. Summary

This section’s Concepts

This section’s Commands

The Instinct That Matters More Than Commands

Picture an investigator’s first 30 minutes after connecting to a breach scene. They walk exactly the course you walked today: opening the login record (auth.log) in /var/log, rummaging through /tmp and /dev/shm for unfamiliar executables, checking /etc for recently changed settings. The expert’s investigative route and this section’s beginner stroll are the same — the difference is speed and interpretive skill, not the map. The map is already in your hands. Attackers move by this same map, so if defenders don’t know it, only the attackers know the roads.

Remember two more things. First, “everything is a file” — the Unix design philosophy. The disk is a file (/dev/sda), the random number generator is a file (/dev/urandom), process information is a file (/proc). That fact, which you confirmed with cat yourself today, is Linux’s power. Second, when you later learn forensics (disk evidence analysis), you’ll meet the procedure “mount read-only to protect the original.” Its foundation is this section’s concept of mounting.

The Linux filesystem feels like a maze at first, but it’s actually a city with well-posted signs. From today on, whatever path you run into, you can guess “which neighborhood is this?” Those who know the roads are not afraid.

Once every box is checked, Step 27 is complete.