Chapter 4 Filesystem, Permissions, Disk
Where things live, users and groups, what the bits mean, links and inodes, find, du versus df, and the three reasons a write fails on a disk with free space.
In plain words
Imagine a big office building. Every room has a purpose (post room, archive, kitchen), every door has a lock with three kinds of keys (the owner's, the team's, everyone else's), and every floor is a separate slab of concrete with a fixed number of desks. A room can look half empty and still have no free desks, or a cleaner can throw a box in the bin while someone is still holding it, so the space is not actually freed.
That is the Linux filesystem. The rooms are the standard directories (/etc, /var/lib, /proc). The locks are permission bits, owners and groups. The floors are mounted filesystems, each with its own blocks and inodes. df, du, find and lsof +L1 are how you walk the building and find out where the space really went.
Why it matters on call
Permission and disk problems are the most common tickets a platform engineer sees: "Permission denied" when a service reads its config, a service account that cannot write to a shared directory, a web server returning 403, a log that was deleted but the disk is still full, writes failing at 3am while df shows free space.
This chapter gives you a method for each: read the path with namei -l and test as the real user with sudo -u; find the space with du -x and find -size; check inodes, deleted-but-open files and reserved blocks in that order. Everything later in the course that runs programs as some user on some disk builds on these rules, and three of the four questions for this topic are classic interview questions.
Lessons
- Where things live
- Users, groups, and who you are right now
- Permission bits and octal
- r and x mean something else on a directory
- setuid, setgid, sticky and umask
- Links and inodes
- find: the expression language
- Disks, mounts and what df is really telling you
- du, df and finding the space
- df shows free space but writes fail
16 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Why does Linux use numbers instead of user names on files?
The kernel only knows UIDs and GIDs; names are a lookup in /etc/passwd, /etc/group or a directory service like LDAP. Files store numbers, so a file owned by UID 1001 belongs to whoever is 1001 on that system. This matters whenever files move between machines (a restored backup, a shared network disk): the same name on two systems means nothing if the numbers differ, and a deleted user's files show a bare number.
Is chmod 777 ever the right fix?
Practically never. It makes the file or directory writable by every user and process on the box, so any compromised service can modify or replace it. It usually hides a real problem, like the wrong owner, a missing group membership or a missing x on a parent directory. Find the actual missing bit with namei -l and sudo -u user test -r, then grant just that.
What is an inode, in one sentence?
The on-disk record for one file: its type, owner, group, permissions, timestamps, size and where its data blocks are, identified by a number, but not its name. Names live in directories as entries pointing at inode numbers. That split explains hard links, why deleting a name does not always free space, and why a filesystem can run out of inodes before blocks.
Why do df and du disagree?
They measure different things. df asks the filesystem how many blocks are allocated in total. du walks directory names and adds up the files it can see and read. Files that are deleted but still open, files hidden under a mount point, and directories du cannot read all make df larger than du. Small differences come from filesystem metadata and the journal.
What is the difference between "Permission denied" and "Operation not permitted"?
They are two different kernel errors. "Permission denied" (EACCES) means a permission bit is missing: the triple that applies to you does not allow the read, write or traverse. "Operation not permitted" (EPERM) means the operation itself is not yours to do, whatever the bits say: chmod on a file you do not own, chown as a non-root user, or deleting someone else's file in a sticky directory. The text tells you which check to look at.