Lion Cipher Lab
Understand inodes and hard links, then find the deleted file that still fills your disk
- Foundations
- Beginner
- ~40 min
- Free · no account required
Why it matters
A file name on Linux is not the file. It is a label pointing at an inode, the record that really holds the file's size, owner, permissions and the location of its data. Once you see that, three things that baffle beginners stop being mysterious: why deleting a big log at 3 a.m. did not give the disk back, why a symbolic link suddenly says 'No such file or directory', and how an intruder's program can keep running after its file was deleted. This is one of the most common real outages on Linux servers, and the same idea is how an analyst copies a deleted malicious binary out of a live machine.…
What you'll learn
- Reading inode numbers and link counts with `ls -li` and `stat`
- Creating hard links and symbolic links, and predicting what survives when the original name is removed
- Recognising the 'df says full, du finds nothing' symptom of a deleted-but-open file
- Finding the process that holds it with `lsof +L1` or `/proc/<pid>/fd`, and freeing the space without breaking the process
- Spotting a running program whose file on disk was deleted (`/proc/<pid>/exe ... (deleted)`) and copying it out for analysis
- Knowing the limits: hard links stay inside one filesystem and never point at directories; inode exhaustion (`df -i`) is a separate failure
Steps in this lab
- What an inode is, in one breath
- Open a Linux terminal and make a scratch folder in your Linux home
- See your first inode number and link count
- Make a hard link and a symbolic link, and compare them
- Remove the original name: the hard link keeps the data, the symlink dangles
- Honest limits of hard links, and the other way a disk can be 'full'
- BEFORE: build the incident, a program writing a big log
- The wrong fix: rm the live log, and watch du and df disagree
- Find the culprit with lsof +L1, or with /proc if lsof is missing
- AFTER: free the space correctly, then stop the process
- Why logrotate has copytruncate and postrotate
- The security angle: a running program whose file was deleted
- Honest negative: /mnt/c is not a Linux filesystem, so do not trust what it tells you
- The judgment: what a pro does differently
- Clean up, and what you just proved