Lesson 27 of 60 beginner

Linux Filesystem, Users & Permissions

Enough Linux to be useful on day one

Open interactive version (quiz + challenge)

Real-world analogy

Linux is like a well-organized warehouse. Every aisle (directory) has a purpose, every item (file) has an owner and rules about who can touch it. The loading dock (sudo) is supervised, and the logbook (permissions) never lies.

What is it?

Linux administration basics cover filesystem navigation, user/group management, permissions, package management, and the sudo/audit model. This is the starter pack that makes you useful on mixed-stack teams.

Real-world relevance

A developer says ‘my app can’t write logs.’ You check /var/log/myapp and find the directory owned by root:root, 755. The app runs as user ‘myapp.’ You chown to myapp:adm, chmod 750. App writes. Problem solved — without root passwords or dangerous shortcuts.

Key points

The filesystem tree — Everything starts at /. Key directories: /etc (configs), /var (logs, spools, databases), /home (users), /root (root user), /usr (installed software), /opt (optional/third-party), /tmp (temp files), /bin & /sbin (binaries).
Users, groups, root — Users live in /etc/passwd, groups in /etc/group, password hashes in /etc/shadow. Root is UID 0 — full power. Real admins don’t log in as root; they use sudo to escalate when needed, and log everything.
File permissions (rwx) — Three triplets: owner, group, others. chmod sets, chown changes owner/group. Numeric form: r=4, w=2, x=1. So 755 = rwxr-xr-x. For directories, x means ‘can enter,’ not ‘can execute.’
Special bits: setuid, setgid, sticky — setuid (s on owner x): file runs with owner privileges (famous: passwd command). setgid on dir: new files inherit the group. sticky bit (t on other x): only owners can delete their files in shared dirs like /tmp.
Common paths you will visit daily — /etc/ssh/sshd_config (SSH), /etc/hosts (static name overrides), /etc/fstab (mounts), /var/log (logs), /etc/sudoers (sudo rules via visudo).
sudo — the audit trail — sudo lets you run one command as another user (usually root) after typing your own password. Commands are logged. sudo -l shows what you’re allowed. Don’t edit /etc/sudoers directly — use visudo to avoid syntax errors that lock you out.
Package managers — Debian/Ubuntu: apt. Red Hat/Rocky/Alma: dnf (or yum on older). Arch: pacman. Alpine: apk. ‘How do I install X?’ depends on the distro. Always update the package index before installing.
Graceful restarts and safe changes — Never kill -9 a service when systemctl restart works. Always test config syntax before restarting critical services (nginx -t, sshd -t). Small discipline, huge outage prevention.

Code example

// Linux day-one essentials

who                   # who's logged in
id                    # your UID/GID and groups
groups                # your groups
pwd                   # where am I?
ls -la                # long list with hidden + perms
cd /etc

# Inspect a user and their groups
cat /etc/passwd | grep alice
id alice

# Add a user and group safely
sudo adduser dave                       # debian/ubuntu
sudo useradd -m -s /bin/bash dave       # portable
sudo usermod -aG sudo dave              # grant sudo

# Change permissions and ownership
chmod 640 /etc/myapp.conf
chown myapp:adm /var/log/myapp

# Edit sudoers safely
sudo visudo

Line-by-line walkthrough

1. Linux essentials script
2. who is logged in
3. user identity and groups
4. group membership
5. current directory
6. long listing with hidden files
7. change to /etc
8. Blank separator
9. Inspect a specific user
10. passwd grep
11. id command
12. Blank separator
13. Create user and group
14. adduser on Debian/Ubuntu
15. Portable useradd with home and shell
16. Grant sudo membership
17. Blank separator
18. Change permissions and ownership
19. chmod config
20. chown on log dir
21. Blank separator
22. Safe sudoers edit with visudo

Spot the bug

App fails to write to /var/log/myapp.
Junior runs: chmod -R 777 /var/log and proudly says ‘fixed’.

Need a hint?

Why is chmod 777 on /var/log a security disaster?

Show answer

That grants every user full read/write/execute on all log files — destroying integrity, enabling tampering, and likely violating multiple policies. Correct fix: chown the specific app directory to the app’s user/group (chown -R myapp:adm /var/log/myapp) and set 750 or 770 as appropriate. Never use recursive 777 as a troubleshooting shortcut.

Explain like I'm 5

Linux is a warehouse. Everyone has a badge (user), belongs to teams (groups), and every box (file) has a tag saying who can open, move, or destroy it. Root is the manager. Sudo is the rare time you borrow the manager’s badge — and everyone writes down when you did.

Fun fact

The concept of sudo came from Berkeley in the 1980s. It’s so deeply embedded in Unix culture that ‘sudo’ has become a verb — and a whole genre of internet jokes about root power.

Hands-on challenge

On Ubuntu in a VM: create a user ‘alice,’ add her to group ‘ops,’ create /srv/ops owned by root:ops with mode 2770 (setgid + rwx for owner+group). Test that new files in /srv/ops inherit group ops.

More resources

Ubuntu server guide (Ubuntu)
Linux File Permissions (DigitalOcean) (DigitalOcean)
Linux for beginners (Josh Madakor) (Josh Madakor)

Open interactive version (quiz + challenge) ← Back to course: IT Jobs Bootcamp