2️⃣Module 2 — The Filesystem

On Ubuntu 24.04 you will see most of these names (a few extras or absences are normal — cloud images add their own):

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

What to read out of it:

• These ~20 names are the top of the entire system. Part B tours what each one is for; by the end of this module you will know where to look for configs, logs, and programs without guessing.
• ls printed names in columns, alphabetically. Names only — no sizes, no dates. Getting more detail out of ls is a skill of its own (B2).
• If you see oddities like bin.usr-is-merged or lost+found, leave them be — they are plumbing, not for daily use.

/home/zaeem
/var/log
/

What to read out of it:

• A new terminal starts in your home directory — /home/zaeem here; yours shows your username (A4 explains home).
• cd itself printed nothing — Module 1's rule at work: silence is success. The two pwd outputs are the confirmations.
• Note what pwd prints for the root: a bare /. The root's name really is that single character.

bash: cd: /nonexistent: No such file or directory
/

What to read out of it:

• The reporter is bash (cd is built into the shell — there is no separate cd program), and No such file or directory is the single most common error message in Linux. You will see it thousands of times; it always means the path was wrong, not the command.
• The second line is the important lesson: a failed cd leaves you where you were. You did not move to a half-right place. After any failed command, your position is unchanged — check with pwd, carry on.

/var
/

What to read out of it:

• .. climbed one level each time: /var/log → /var → /.
• Try one more cd .. from /. Then pwd. You stay at / — the root is its own parent, so climbing past the top quietly does nothing. No error, no movement.

/home/zaeem
/home/zaeem
/home/zaeem

What to read out of it:

• Both cd forms landed in the same place; use whichever your fingers prefer.
• The echo line is the revealing one: ~ is not understood by programs — the shell replaced it with /home/zaeem before echo ran, exactly like $SHELL in Module 1. Programs only ever see the expanded path.
• Yours shows your username, and on a cloud VM it may be /home/ubuntu — or /root if you are the root user.

An absolute path starts with / and gives the complete address from the root — /var/log/syslog means the same file no matter where you stand. A relative path has no leading / and is resolved against the current working directory — log/syslog names /var/log/syslog only if you are standing in /var. Absolute paths are unambiguous; relative paths are shorter but context-dependent.

The details that separate candidates: stating the operational rule that follows — interactive typing may use relative paths; automation should use absolute ones, because scripts run from unpredictable working directories; and knowing . and .. are real names present in every directory, which is why ./script and ../config work at all.

pwd — print working directory. It prints the absolute path of where this shell currently stands. Each shell has its own working directory, so two terminals can be in different places; a failed cd leaves it unchanged.

The details that separate candidates: mentioning why it matters — every relative path in every command is resolved against this location, so pwd before a destructive command is a cheap safety check; and noting the prompt usually shows the location too, with ~ standing for home.

cd path — with an absolute or relative path; cd .. for the parent, plain cd (or cd ~) for home. A useful extra: cd - returns to the previous directory, handy for bouncing between two locations.

The details that separate candidates: knowing cd is a shell builtin, not a program — it must be, because a separate program could never change the shell's own position. Candidates who can explain why cd cannot be an external program demonstrate they understood Module 1's process model preview.

alternatives.log  apt  bootstrap.log  btmp  dmesg  dpkg.log  faillog
kern.log  lastlog  syslog  ...
/home/zaeem

What to read out of it:

• The exact file list varies with what the machine has been doing — that is the nature of a log directory. What matters: you inspected a faraway directory while standing at home. cd is for working somewhere; ls with a path is for looking.
• pwd confirms your position never changed. Look-don't-touch commands like this are how you explore production machines safely.

-rw-r--r-- 1 root root 3 Sep  2 15:14 /etc/hostname

(The size and date are this machine's own — the size is simply the hostname's length in characters, newline included; yours will differ.) Below, an excerpt of the directory listing — yours will differ in files and sizes:

total 808K
-rw-r--r-- 1 root   root   45K Sep  2 14:22 alternatives.log
drwxr-xr-x 2 root   root  4.0K Sep  2 14:22 apt
-rw-rw---- 1 root   utmp     0 Apr 10 02:20 btmp
-rw-r--r-- 1 root   root  672K Sep  2 15:14 dpkg.log

What to read out of it, column by column:

• Column 1, first character: - means regular file, d means directory. Spot apt — it is a directory inside /var/log. The remaining nine characters (rw-r--r--) are permissions — Module 4's entire subject; until then, just recognise the shape.
• Column 2 (the small number) counts links — Module 3 explains it; ignore for now.
• Columns 3–4: the owner and group — root root for system files; utmp on btmp is your first sighting of a non-root group. Module 4 again.
• Column 5: size. With -h: 45K, 4.0K. A size of 0 is a real and common thing — btmp here is an empty file, patiently waiting for content.
• Columns 6–7: last-modified date and name. The total 808K header line is the directory's blocks-in-use summary, not a file — a classic source of confusion when counting lines.

adduser.conf
alternatives
apparmor.d
apt
bash.bashrc
...

then a handful of log names, then — very likely — an empty or nearly-empty /tmp.

What to read out of it:

• The exact names and order are your machine's software inventory, so they will differ — a stock server also shows apparmor and apport early in the list; read the block above as a shape, not a checklist. /etc reads like an index of everything installed: one config file or subdirectory per component, names ending in .conf everywhere. You cannot memorise it; you navigate it by knowing the component you are after.
• An empty /tmp is healthy. It fills as programs scratch about and empties on reboot.
• The pipe symbol and head got a one-line loan from Module 3 to keep long listings polite — full treatment there.

One tree rooted at /, laid out by the Filesystem Hierarchy Standard: /etc for system configuration, /var for growing data (chiefly logs in /var/log), /home for users' files, /usr (with /bin merged into /usr/bin on modern distros) for installed programs, /tmp for reboot-wiped scratch, /boot for the kernel, /opt for third-party software, and /dev, /proc, /sys as kernel-provided views rather than real storage. All storage devices are mounted into this one tree — there are no drive letters.

The details that separate candidates: citing the FHS by name; knowing /root is root's home, not the root directory; and mentioning the usr-merge as evidence your knowledge is current rather than copied from a 2010 tutorial.

Long-format listing: one row per entry with type-and-permissions string, link count, owner, group, size, modification time, and name. The first character types the entry (- file, d directory, l symbolic link). Add -h for human-readable sizes, -t/-r for time-sorted views — ls -ltr puts the newest files at the bottom, which is the practical way to spot what just changed in a log directory.

The details that separate candidates: reading a sample row aloud fluently, column by column, without hesitating — and knowing the total header line is block usage, not a file. Interviewers actually put a row in front of candidates; fluency here is checkable in ten seconds.

notes  todo.txt
day1.txt

What to read out of it:

• Four silent commands, two listings as proof. notes and todo.txt sit in the sandbox; day1.txt sits inside notes — created from outside it, because any command accepts a path, not just a name.
• Empty files are legitimate: touch todo.txt made a real file of size 0 (check with ls -l — recall btmp in B2.1).
• If mkdir practice says File exists, you ran it twice — either remove the old one at the end of this Part, or just cd practice and continue; everything below re-runs cleanly.

backup.txt  notes  todo.txt
cp: -r not specified; omitting directory 'notes'

What to read out of it:

• The file copy worked silently; ls shows the twin.
• The directory copy was refused, with the fix named in the error: -r not specified. Note the word omitting — in a multi-file copy, cp would have copied the files and skipped the directory, a partial success. Errors that name the missing flag are gifts; take them.
• Now do it right: cp -r notes backup-notes — then ls backup-notes to confirm day1.txt travelled too. Clean up the copies: rm backup.txt and rm -r backup-notes (rm is C4, one section early — it deletes; -r means recursively).

notes  tasks.txt
notes
day1.txt  tasks.txt

What to read out of it:

• First listing: todo.txt is gone as a name; tasks.txt holds its contents. Nothing was copied; one label changed.
• After the second move, the sandbox root contains only notes, and the file sits inside. The trailing / on notes/ is optional but professional: if notes did not exist, mv tasks.txt notes would silently rename the file to notes — the slash makes "into a directory" explicit and turns that mistake into an error instead.

rm: cannot remove 'notes': Is a directory
rmdir: failed to remove 'notes': Directory not empty

then silence, and a final ls with no output at all — the sandbox is empty.

What to read out of it:

• Two different guards refused for two different reasons: rm (without -r) will not touch directories; rmdir will not touch contents. Each error names its own rule.
• The explicit path — delete the files, then the empty directory — is slower than rm -r notes, and that is its virtue: every deletion was named, seen, and intended. Use rm -r when you mean it, not as a habit.
• An ls that prints nothing is the correct final state: empty directory, empty output. (Silence, again.)

cp duplicates: source remains, destination is a new, independent copy of the data — so it costs time and disk proportional to size, and needs -r for directories. mv relocates or renames: on the same filesystem it rewrites only the directory entry — instant regardless of size, no -r needed, source name gone. Across filesystems, mv degrades into copy-then-delete and inherits cp's costs. Both overwrite existing destinations silently; -i/-n temper them.

The details that separate candidates: the same-filesystem rename mechanism (directory entry, not data) — it explains the instant-rename and the slow-cross-device cases in one stroke; and volunteering the silent-overwrite behaviour unprompted, which signals operational scar tissue rather than book knowledge.

Deletes the named paths and everything beneath them: -r descends recursively into directories; -f forces — no prompts, and missing files are not treated as errors. Nothing goes to any trash; recovery is not a feature. Modern GNU rm refuses rm -rf / itself (--preserve-root by default), but nothing refuses rm -rf of the wrong non-root path.

The details that separate candidates: explaining why -f exists legitimately (idempotent cleanup in scripts — "make sure this is gone" without failing when it already is) rather than painting it purely as a footgun; then giving one concrete guardrail habit — ls the argument first, or run with echo in front to preview what the shell expanded.

Both are mv: mv old.txt new.txt renames; mv file.txt /some/dir/ moves; mv old.txt /some/dir/new.txt does both at once. Rename is a move — one operation in Linux, not two.

The details that separate candidates: the trailing-slash habit (dir/ fails loudly if dir is missing, where mv file dir would silently rename file to dir) — a tiny convention that prevents a real class of accidents, and exactly the kind of detail that makes an interviewer trust your hands on production.

The first line completes to ls /boot/ after one Tab — a unique match, filled in whole, trailing slash confirming a directory. The second is the ambiguous case: the first Tab stays quiet, because three names match — /var/local, /var/lock, /var/log — and you already typed their shared prefix. The second Tab lists all three candidates and re-offers your line for editing.

What to read out of it:

• Completion filled in the existing name, trailing slash included — the slash confirms it is a directory.
• Read Tab's three answers as data: instant completion = unique match; silence = ambiguity (double-Tab to see the choices); nothing on double-Tab either = the path you are imagining does not exist. From today, typing a long path by hand is a small code smell — and when Tab refuses to complete, stop and ls, because something about your assumption is wrong and you just caught it early.

practice
.  ..  .bash_history  .bash_logout  .bashrc  .profile  practice

What to read out of it (your dotfile list will vary — that is the point):

• The first listing shows only your sandbox. The second reveals what every home accumulates: .bashrc and .profile (bash's per-user startup configs — Module 5 edits them), .bash_history (your past commands — it appears only after your first shell session has ended, so a brand-new VM may not have it yet).
• . and .. head the list: the directory itself and its parent, as real entries.
• The more tools you use, the more dotfiles appear — .ssh, .gitconfig, .docker. A messy ls -a in home is the fingerprint of a working engineer.

my file.txt
rm: cannot remove 'my': No such file or directory
rm: cannot remove 'file.txt': No such file or directory

then silence, and an empty final ls.

What to read out of it:

• The unquoted rm produced two errors — proof it received two arguments, my and file.txt, neither of which exists. The shell split the name before rm ever saw it.
• Read the quoted single name in ls output versus the two names in the errors until the mechanism feels obvious. This exact confusion, at scale, is why Module 10's scripting rules quote every variable.
• A darker variant to imagine (do not build it): if files named my and file.txt had existed, the unquoted command would have deleted them — successfully, silently, wrongly.

ls -a shows everything, including dotfiles and the ./.. entries; ls -la (the form the question's own answer cites) combines it with long format. ls -A is the scriptable variant: all dotfiles but without . and ...

The details that separate candidates: stating that hiding is only the leading-dot naming convention — no permission or security machinery involved; knowing -A vs -a; and mentioning what dotfiles are for (per-user program config in home), which turns a flag-recall question into a systems answer.

ls -a in the directory of interest — most usefully your home, where programs keep their dotfile config (.bashrc, .ssh, .gitconfig). Nothing special "unhides" a file; the dot in the name is the whole mechanism, so renaming file to .file hides it and back again.

The details that separate candidates: the rename observation — it demonstrates you understand the mechanism rather than memorising a flag — plus one operational note: forgetting dotfiles is a classic backup/copy bug, since a bare cp * idiom misses them (globbing details in Module 5).

Ticket text: "After following a blog tutorial, our engineer says the app ignores every config change. They have been editing nginx.conf — it's in their home directory. Explain what happened and where things actually belong."

Worked answer: the engineer edited ~/nginx.conf — a file in their home, which no service reads. System-wide configuration lives under /etc (here, /etc/nginx/); the blog assumed the reader was standing there, and a relative filename plus the wrong working directory created a private copy instead. Diagnosis in two commands: pwd (where were they standing?) and ls -l /etc/nginx/ (the real config, with its modification time proving it never changed). The habits that prevent recurrence: absolute paths when editing system files, and reading the FHS map once — configs in /etc, logs in /var/log, your experiments in home.

Ticket text: "A teammate ran rm -rf meaning to clear a build directory and deleted a release archive instead. Draft the 'what happened / why is there no undo / what changes' section of the postmortem."

Worked answer: what happened — an rm -rf with a wrong path (typo, wrong working directory, or an unnoticed space splitting one argument into two) deleted a tree that matched the mistake, not the intent. Why no undo — deletion removes the name immediately; the underlying data is reusable by the next write, and servers have no trash can, so recovery without backups is not a plan. What changes — the four guardrails, cheapest first: ls the exact argument before any recursive delete; never reflexive -f; absolute paths in anything destructive; destructive automation gets a dry-run mode and runs on one host before many. Note what the postmortem should not say: "be more careful" — process beats vigilance.

Ticket text: "A hand-rolled backup step does cp of several items into a dated folder. Files arrive; the reports directory never does. No one saw an error for weeks. Explain and fix."

Worked answer: cp without -r prints cp: -r not specified; omitting directory 'reports' and continues copying the rest — a partial success. Nobody watches a nightly job's output, so the message scrolled into the void for weeks. Fix: cp -r for any copy that may include directories, then verify the copy by listing the destination (ls of the expected subtree) rather than trusting silence. The deeper lesson, which Modules 5 and 10 formalise: unattended jobs must check their own results — exit codes and verification steps, not human eyeballs on scrollback.

Ticket text: "An engineer renamed a 40 GB export with mv and it returned instantly. They re-ran it 'to be safe' and got an error. Are we corrupted?"

Worked answer: all is well. On the same filesystem, mv rewrites the directory entry — the name-tag — and never touches the 40 GB of data, so instant is correct. The re-run error (No such file or directory) is the proof of success: the old name no longer exists. Confirm with ls -lh on the new name — same size, same modification time as before the rename (the data was untouched, so its timestamp did not change). What would be slow: moving the same file to a different filesystem, where mv must copy every byte and then delete the original — Module 12 shows how to know which case you are in before you run it.