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: Today’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 chapter, 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

Today’s Tools at a Glance

Category	Details
Language & environment	bash — Ubuntu terminal (VM or WSL)
Today’s commands	`ls /` (view the top level), `cat /proc/...` (read virtual files), `df -h` (free disk space), `du -sh` (folder size), `which` (a command’s real location)
Concepts needed	FHS (Filesystem Hierarchy Standard), root (`/`) and mounting, virtual filesystems, /proc and /dev

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:

Folder	Role	Analogy
`/bin`, `/sbin`	Executables for basic commands and system commands	Toolbox
`/etc`	Configuration files	The document cabinet in the building management office
`/home`	Users’ home folders	Everyone’s own room
`/var`	"Changing data" like logs	Diaries and ledgers
`/tmp`	Temporary files (wiped on reboot)	Scratch paper on the workbench
`/usr`	Installed programs and libraries	Warehouse
`/proc`	A virtual folder the kernel creates in real time	The computer’s inner thoughts
`/dev`	Shows devices (disks, terminals, etc.) as files	Equipment connectors
`/root`	root’s home folder (off-limits to regular users)	The admin’s office

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 today’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

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

(Depending on the environment, live output has more entries than this — the WSL Ubuntu verified on 2026-09-09 had extras like init, snap, lost+found, and bin.usr-is-merged. All the map’s core folders are right there inside.)

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

(Verified 2026-09-09 on WSL Ubuntu 24.04. Your environment’s list will differ depending on installed programs.)

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

(Verified 2026-09-09.)

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

(Verified 2026-09-09. Yours will show your computer’s CPU model and clock speed.)

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

Make a prediction: If you check this file’s size with ls -l /proc/cpuinfo, what will it say? ① It’s CPU info, so a few KB ② 0 bytes. Predict, then check. (Answer: 0 bytes — the live result is -r--r--r-- 1 root root 0 ... /proc/cpuinfo, with 0 in the size column. Being a virtual file, its size isn’t fixed until it’s read. Verified 2026-09-09.)

cat /proc/meminfo | head -5

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

(Verified 2026-09-09.)

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

(Verified 2026-09-09.)

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% /
...

(Verified 2026-09-09 — this is the line for the disk mounted at / in WSL. On your VM it will usually look like /dev/sda1 40G ..., and the live screen also showed several virtual filesystem lines such as tmpfs — covered in Wall 4.)

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

(Verified 2026-09-09 — the live environment was an admin account, so the home was /root. Yours will look like 1.2G /home/yourname.)

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

(Verified 2026-09-09.)

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

(Verified 2026-09-09.)

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

Draw today’s nine top-level folders as a tree diagram, add a one-line description to each, and save it as filesystem-map.txt
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
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
Read two more files under /proc with cat (anything besides cpuinfo and meminfo), and confirm with ls -l that their size is 0
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.

5. Model Answers & Completion Criteria

Mission Model Answer

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 (deleted on reboot)
├─ /proc  : virtual folder the kernel creates in real time (inner thoughts)
└─ /dev   : where devices are shown as files (connectors)

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

How to verify: ① Does the map have all nine folders, with descriptions in your own words? ② In step 2, did /proc/PID/cmdline show sleep 300? If so, Step 26’s process world and today’s file world connected into one. ③ Was the size column of ls -l /proc/... 0? ④ Is jobs empty at the end (cleanup check)?

Exercise Solutions

Question 1 solution. ① /etc/nginx — configs go in /etc. ② /var/log/auth.log — logs go in /var. ③ /bin or /usr/bin — verifiable with which grep (verified 2026-09-09: /usr/bin/grep). ④ /tmp or /dev/shm — temporary spaces that vanish on reboot and draw less suspicion, which is why attackers love dropping tools there.

Question 2 solution. It’s not broken — it’s the normal behavior of a virtual file. Files in /proc have no content stored on disk; the kernel generates "the current state" on the spot at read time. Since the size isn’t fixed until it’s read, it shows as 0 (size 0 confirmed live on 2026-09-09). The rule: for files in /proc and /sys, "ignore the size and only view them with cat."

Question 3 solution. df -h measures how full the whole disk (filesystem) is; du -sh folder measures how much that folder eats. When a report comes in: ① check which disk is full with df -h → ② narrow down the culprit folder inside it with something like du -sh /var/* | sort -h | tail. The usual culprit is accumulated logs.

Question 4 solution. A mount — the USB’s contents are "hung onto" a point in the tree (usually /media/username/something). That’s how every storage device enters the single tree that starts at /. The "Mounted on" column at the far right of df -h output shows those attachment points.

Completion Criteria Checklist

[ ] I can state the roles of the nine top-level folders
[ ] I remember and can apply "configs in /etc, logs in /var, my stuff in /home"
[ ] I can explain why /proc is a virtual folder and what 0 bytes means
[ ] I can explain the difference between df -h and du -sh
[ ] I can say what a mount is in one sentence
[ ] I can find a command’s real location with which
[ ] Mission: I completed filesystem-map.txt and the /proc exploration

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. Backups save you from 90% of config file accidents. (Today’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 section 3-5 live capture).

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

Today’s Concepts

Concept	One-line description
FHS	The standard promise for Linux folder layout
Root (`/`)	The single root where every path begins
Mount	Hanging a storage device onto a point in the `/` tree
/proc	A virtual folder the kernel generates in real time — size 0 is normal
tmpfs	A virtual filesystem on memory (/dev/shm, etc.)

Today’s Commands

Command	What it does
`ls /`	List top-level folders
`cat /proc/cpuinfo`, `cat /proc/meminfo`	Read hardware info generated by the kernel
`cat /proc/1/cmdline`	The launch command of PID 1 (the ancestor process)
`df -h`	Free space of the whole disk (human units)
`du -sh folder`	Total size of that folder
`which command`	The real location of a command’s executable

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 today’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 today’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. Click the checkbox in the sidebar to save your progress.

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

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

1. Learning Objectives

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

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

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

2-3. /proc — A Living Virtual Folder

3. Follow Along

3-1. Touring the Top-Level Folders

3-2. Exploring /proc

3-3. Viewing Disk Capacity — df and du

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

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

4. Missions & Exercises

Mission — Draw Your Linux’s Filesystem Map

Exercises

5. Model Answers & Completion Criteria

Mission Model Answer

Exercise Solutions

Completion Criteria Checklist

6. Common Pitfalls & Fixes

7. Summary

Today’s Concepts

Today’s Commands

The Instinct That Matters More Than Commands

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