Mission 13 of 30
Ownership and Groups Without Fear
Explain who owns a file and when ownership changes require care.
Learn users, groups, ownership, and why admin ownership commands are optional rather than required.
Your outcome: You understand who owns a file without needing to create or delete real users.
Practice inside
Practice inside
~/linux-practice. Check your setup before you begin.
Prerequisite: File Permissions Deep Dive
.
What you’ll practice
- Inspect user identity
- Read ownership columns
- Recognize admin-only ownership commands
The mental model
- Every file has an owner and group.
- Your regular account should own practice files.
- sudo changes the risk level.
Try it in your terminal
Who am I?
Read-only system viewShows your username, IDs, and groups.
Run from ~/linux-practice
cd ~/linux-practice
whoami
id
groupsInspect ownership
Read-only system viewShows ownership on your file and reads user/group databases.
Run from ~/linux-practice
touch owned-by-me.txt
ls -l owned-by-me.txt
head -5 /etc/passwd
head -5 /etc/groupOptional admin ownership examples
Optional adminThese change real system state. They are explained, not required for this safe course.
Run from advanced users only
sudo chown username:groupname file.txt
sudo adduser testlearner
sudo userdel -r testlearnerPut it into practice
- Use ls -l and identify owner and group columns.
- Use id and identify your primary group.
Check your result
id and ls -l explain current ownership.
Common mistakes
- A tutorial says 'run this with sudo' and you type it without thinking. Stop. Read the command. Ask yourself: 'Do I actually need admin rights for this?' Most beginner tasks don't. Running `sudo` because someone else's blog post said so is how you accidentally change ownership of system files and create problems you can't easily fix.
- You see a file owned by 'root' and decide to `chown` it to yourself. That file is probably owned by root for a reason — maybe it's a system config or a package file. Changing ownership on files you didn't create is a good way to break things. Inspect first with `ls -l`. Understand why it's owned by root before touching it.
Check your understanding
Explain these in your own words. If you’re unsure, revisit the examples before moving on.
- Which command shows your user and group IDs?
- Why are adduser/userdel not part of the core safe path?
Your practice, your pace
Loading saved progress…