Linux filesystem cheat sheet circulates

A Linux filesystem cheat sheet is making the rounds because it solves a very specific pain: when a box is broken, you do not want theory, you want to know where things live. That means config files, logs, mounts, service units, and the handful of commands that tell you what failed. The version getting shared is a GitHub Gist updated last month, and it is basically a one-page map for fast triage. It leans on the same directory layout the Linux Foundation’s Filesystem Hierarchy Standard defines, plus the standard systemd unit paths most distros use. ### What is the cheat sheet actually showing? It is not just a command list. The useful part is that it ties commands to places. `/etc` for host-specific config, `/var` for changing data like logs, `/usr` for installed software, `/home` for user data, `/proc` and `/sys` for kernel-exposed runtime state, and `/mnt` or `/media` for mounted storage. That sounds basic, but in practice it is the difference between “Linux feels random” and “I know where to look next.” ### Why do those directories matter so much? Because Linux troubleshooting is usually location-based before it is tool-based. If a service will not start, you check config under `/etc`, logs under `/var/log` or `journalctl`, and unit files under systemd’s search path. If a machine fails after reboot, you check mounts and `/etc/fstab`. If a user says files disappeared, you care about the mental model made visible. ### Where do service files actually live? This is one of the most practical parts. Package-installed unit files generally live under `/usr/lib/systemd/system`, while administrator overrides and custom units live under `/etc/systemd/system`. That split matters because `/etc` takes precedence. So if a service behaves differently from the packaged default, the first question is whether someone changed it at 2 a.m., but a good cheat sheet reminds them to check. ### Why include permissions on the same page? Because bad permissions cause boring, expensive failures. A daemon cannot read its config. A script loses execute bits. A shared directory needs the sticky bit and nobody remembers the octal. Pairing filesystem locations with permission patterns is smart because the problems show up together. You find the file, then you need to know whether owner, group, or mode is the real issue. ### What about mounts and recovery? Turns out that is where the sheet gets more valuable. It includes disk and filesystem commands, plus automatic mounting through `/etc/fstab`. In recovery work, that is the difference between “the disk is gone” and “the mount failed because UUIDs changed, options are wrong, or the filesystem is read-only.” A lot of Linux outages are not glamorous — they are just storage, boot, or service-order problems. ### Is this official Linux guidance? Not exactly. The Gist itself is community-made. But the layout it teaches is not arbitrary. It lines up with the Filesystem Hierarchy Standard, and the service locations line up with systemd’s documented unit search paths. So the sheet works because it compresses real conventions, not because it invents a new framework. Because Linux knowledge is still weirdly uneven. Plenty of people can paste commands from memory, but fewer can explain why config is in one tree, logs in another, and package units somewhere else again. A compact map helps with onboarding, but it also helps experienced people under pressure. Basically, it shortens the gap between “I know Linux commands” and “I can debug a Linux system.” ### Bottom line The story is not that someone invented a new Linux trick. The story is that a concise, practical map of the Linux filesystem hit the right nerve. When systems break, knowing where to look is half the job — and this kind of cheat sheet turns that into muscle memory.