Files, Inodes & Permissions

In this module, you'll learn to:

• Find your way around the standard Linux directory layout
• Explain inodes, hard links, and symbolic links, and what deleting a file really does
• Read and set permissions, including the special bits and ACLs, and diagnose "Permission denied"

Before you start: finish Shell Survival. Open a shell on your lab VM with multipass shell lab.

Where things live

Every Linux system follows roughly the same layout, so once you know it you can find your way around any server. These directories cover most of what you'll touch:

Linux treats almost everything as a file: devices, kernel settings, even running processes. The first character of ls -l output tells you which kind you're looking at: - for a regular file, d a directory, l a symbolic link, c or b a device, s a socket, p a pipe.

What a file really is

A file name is just a label. The file itself is an inode: a record that holds the file's owner, permissions, size, timestamps, and where its data sits on the disk. A directory is a list that maps names to inode numbers.

echo "hello" > notes.txt
ls -i notes.txt          # the inode number
stat notes.txt           # everything the inode holds

ln notes.txt hard.txt    # a hard link: a second name for the SAME inode
ln -s notes.txt soft.txt # a symbolic link: a small file holding a path
ls -li notes.txt hard.txt soft.txt

rm notes.txt
cat hard.txt             # still works: the inode still has a name
cat soft.txt             # fails: the path it points to is gone

Two facts here explain real incidents later in this track:

• Deleting a file removes a name, not the data. The space is freed only when no names point to the inode and no running program has the file open. That's why deleting a huge log that a service is still writing to doesn't free any disk space.
• A disk has a fixed number of inodes, as well as a fixed amount of space. Millions of tiny files can use up every inode while df -h still shows free space. df -i shows inode usage.

Who can do what

Every file and directory has an owner, a group, and three sets of permissions: for the owner (u), for members of the group (g), and for everyone else (o).

ls -l notes.txt
-rw-r----- 1 ubuntu devteam 6 Oct  1 10:00 notes.txt
 └┬┘└┬┘└┬┘   └─┬──┘ └──┬──┘
  u  g  o    owner   group

Each set is some combination of r (read), w (write), and x (execute). Permissions are often written as numbers, where r = 4, w = 2, and x = 1, added up for each set. So rw-r----- is 6, 4, 0, written 640.

chmod 640 notes.txt          # owner rw, group r, others nothing
chmod u+x script.sh          # add execute for the owner
chmod g-w,o-r report.txt     # remove group write and others' read
sudo chown alice notes.txt   # change the owner
sudo chown alice:devteam notes.txt   # change owner and group

On a directory, the same letters mean something different, and this is where most confusion comes from:

To open /srv/reports/2026/q3.txt, you need x on /, /srv, /srv/reports, and /srv/reports/2026, as well as r on the file itself. One missing x anywhere along the path blocks you, whatever the file's own permissions say. Root skips all of these checks.

New files get their starting permissions from your umask, a set of bits to remove. Run umask to see yours. On Ubuntu it's usually 0002 for regular users, which gives new files 664 and new directories 775.

setuid, setgid, and sticky

Three extra bits handle cases the basic permissions can't:

• setuid on a program: it runs as the file's owner, not as you. ls -l /usr/bin/passwd shows rws, which is how a normal user can change their own password in a file only root can write.
• setgid on a directory: new files inside get the directory's group, not the creator's. This is the key to shared team folders.
• sticky bit on a directory: only a file's owner can delete it, even if everyone can write to the directory. ls -ld /tmp shows drwxrwxrwt; the t is the sticky bit.

When owner, group, and other aren't enough, for example "everyone in the group, plus one auditor who can only read", use an ACL (access control list). A + at the end of the permissions in ls -l means a file has one.

Build a shared team folder

Set up a folder where everyone in a team can create and edit files, and nobody else can see in:

# A team group and two users in it
sudo groupadd devteam
sudo useradd -m -s /bin/bash -G devteam alice
sudo useradd -m -s /bin/bash -G devteam bob

# The folder: owned by the group, and setgid (the 2 in 2770)
sudo mkdir /srv/team
sudo chown root:devteam /srv/team
sudo chmod 2770 /srv/team

# A default ACL: every new file is group-writable, whatever each user's umask
sudo apt install -y acl
sudo setfacl -d -m g:devteam:rwx /srv/team

# Test it: alice creates a file, and bob can edit it
sudo -u alice touch /srv/team/plan.txt
sudo -u bob sh -c 'echo "bob was here" >> /srv/team/plan.txt'
ls -l /srv/team
getfacl /srv/team/plan.txt

# Everyone else is kept out
ls /srv/team

The last command fails for ubuntu, which isn't in devteam. That's the point: the folder is private to the team.

Permission denied, with 777

Someone reports they can't read a quarterly report. They've already tried chmod 777 on the file, and it didn't help. Set up the same situation:

sudo mkdir -p /srv/reports/2026
echo "Q3 numbers" | sudo tee /srv/reports/2026/q3.txt
sudo chmod 777 /srv/reports/2026/q3.txt
sudo chmod 700 /srv/reports

# As your normal user:
ls -l /srv/reports/2026/q3.txt
cat /srv/reports/2026/q3.txt

Your job: let normal users read the report, without making anything world-writable. Try it before opening a hint.

Key terms

• Inode: the record behind a file name: owner, permissions, size, and where the data is.
• Hard link and symbolic link: a second name for the same inode, or a small file pointing to a path.
• Permission bits: r, w, and x for the owner, the group, and others, often written as numbers like 640.
• Traverse: passing through a directory, which needs x on it.
• umask: the bits removed from a new file's permissions.
• setuid, setgid, sticky bit: run as the owner; inherit the directory's group; only owners can delete.
• ACL: extra permission entries for specific users or groups.

Pop quiz

Five questions: three on the ideas in this module, and two scenarios where you apply them. The order changes every time you take it, and 4 out of 5 passes.