Linux Level 2: Control Your System

Master sudo, file permissions, users, groups, and pipes on Linux.

Introduction

30 Second Summary

Imagine sharing a computer with other people and having no control over who reads your private files or changes your system settings. Linux gives you a built-in permission system that puts you in charge of exactly who can access what.

In this project, you will build a personal admin toolkit that proves you can control your Linux system. You will write a bash script from scratch, manage file permissions and users, and generate a system report using pipes and redirection.

What You'll Build

When you are done, you will run your own system info script from the terminal, watch it report your username and top running processes, then pipe all of that output straight into a saved report file with a single command.

By the end of this project, you'll have:

A running sysinfo.sh script you wrote yourself that prints your system information to the terminal. You can pipe its output into a saved report file with a single command.
The ability to read any file's permission string and change it using both symbolic mode (u+x, g-w) and numeric mode (755, 700).
Hands-on experience creating and removing users and groups, switching between accounts, and sharing folders with specific people using group permissions.
Secret Mission: Build a File Type Census script that counts every file type in a directory using pipes and command substitution.

Are there any prerequisites?

This project picks up where Linux Level 1 left off. You should have Linux Mint XFCE installed on your computer and be comfortable with basic terminal commands like cd, ls, mkdir, and nano.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters for your Linux skills.

Set Up Your Workspace and Superuser Powers

Linux protects important system files from regular users. Before you can do any real admin work, you need to understand who has power on the system and how to borrow that power safely.

In this step, you'll create a safe practice workspace, discover what happens when you try to access protected files, and learn the one command that grants temporary superuser access.

In this step, get ready to:

Create a safe practice workspace in ~/level2-practice.
Use sudo to break through a "Permission denied" wall.
Enter and exit a root shell safely.

Create your practice workspace

Everything you do in this project lives inside one folder. That way nothing on your real system can break, and cleanup is easy at the end.

In your Terminal, create the practice folder and move into it by running these commands:

mkdir ~/level2-practice
cd ~/level2-practice

Confirm you're in the right place by running:

pwd

You should see /home/yourusername/level2-practice (with your actual username in place of yourusername).

Check which user you're logged in as by running:

whoami

You should see your Linux username printed on the screen. This is the regular user account you'll be working from throughout the project.

Seeing a different folder path?

If pwd does not show level2-practice at the end of the path, the cd command may not have run. Try running cd ~/level2-practice again on its own.

If you get "No such file or directory", the mkdir command did not create the folder. Run mkdir ~/level2-practice again, then cd ~/level2-practice.

Still stuck? Help me figure out why cd or mkdir is not working in my Terminal.

Discover what sudo can do

Linux has a special file called /etc/shadow that stores encrypted password data for every user on the system. It is so sensitive that only the root user (the superuser) is allowed to read it.

Try to read this file as your normal user by running:

cat /etc/shadow

You'll see a "Permission denied" error. Linux blocked you because your regular user account does not have the authority to read this file.

What do you think will happen if you add one word in front of that same command? Try it out.

Run the same command with sudo in front, piped to head to see just the first few lines:

sudo cat /etc/shadow | head -n 3

When prompted, type your password and press Enter. You should see three lines of encrypted password data appear.

What just happened?

The sudo command stands for "superuser do." It temporarily borrows root (superuser) privileges to run the command that follows it. Your regular account stays the same. You just got a one-time power boost.

The | head -n 3 part is a pipe. It takes the output of cat and passes it to head, which shows only the first 3 lines. You'll learn a lot more about pipes in Step 4.

Nothing appears when you type your password?

This is completely normal. Linux hides your password as a security feature. It does not show dots, asterisks, or any characters at all. Just keep typing your password and press Enter.

If you see "incorrect password," try again carefully. You have 3 attempts before sudo locks you out temporarily.

Still not working? Help me troubleshoot my sudo password prompt.

Enter and exit the root shell

Running sudo before a single command is the safe way to use superuser powers. But there is another way: you can log in as root entirely. This is like handing over the master key to every room in the building.

Be careful with this next command

The command below opens a full root shell. While you are in it, every command runs with superuser power. A typo could delete important files. Follow the instructions exactly and type exit immediately after you see the prompt change.

Open a root shell by running:

sudo -i

Look at your terminal prompt. It changed from $ to #. That # symbol means you are now root. Every command you run has full superuser power.

Leave the root shell immediately by typing:

exit

Your prompt changes back to $. You are your normal user again.

The golden rule of root access

Never stay logged in as root. Use sudo for individual commands instead. A single careless rm command as root could wipe out your entire system.

Think of sudo as borrowing the master key for one door, then handing it right back. Running sudo -i is like taking the master key and walking around with it in your pocket. The longer you hold it, the more likely something goes wrong.

Still seeing the # prompt?

If your prompt still shows #, you are still inside the root shell. Type exit and press Enter. You should see the prompt change back to $.

Need help? Help me get out of my root shell in Linux.

Time for one final proof that sudo works. Before you run the next command, predict: what name do you think will be printed?

Run this command to see who you become when using sudo:

sudo whoami

You should see root printed on the screen. That single word proves that sudo temporarily made you the superuser for just that one command. Your prompt still shows $ because you are safely back to your normal account.

Test your sudo knowledge

See how many of these you can answer before moving on:

What does "sudo" stand for?
Why does Linux hide your password when you type it after a sudo command?
What is the difference between running sudo command and logging in as root with sudo -i?
Why is it considered dangerous to stay logged in as root?
If you see "Permission denied" when trying to read a file, does that always mean you need sudo?

Want to check your answers? Quiz me on these sudo review questions and explain each answer.

You now have a safe workspace and you know how to borrow superuser powers with sudo. Next up, you'll create your first script and discover that "Permission denied" does not always mean you need sudo. There is a completely different kind of lock on your files, and you'll learn how to read it and change it.

Control File Permissions

In Step 1, you broke through "Permission denied" with sudo and discovered how the superuser has access to everything on the system.

But what happens when you create your own script and it still refuses to run? Using sudo is overkill for files you own.

Every file in Linux has permission locks that control who can read, write, and execute it. In this step, you will create a script, discover why it refuses to run, and learn to control those locks with chmod.

In this step, get ready to:

Create a bash script and discover why it will not run.
Learn to read and change file permissions with chmod.
Lock down a script so only you can access it.

Create a script and hit Permission denied

Think of file permissions like locks on a door. Every file has three sets of locks: one for the owner, one for the group, and one for others (everyone else). When you create a new file, Linux leaves the "execute" lock closed by default.

Open a new file called hello.sh in nano by running this command:

nano hello.sh

Type the following script inside the nano editor:

#!/bin/bash
echo "Hello from my script!"
echo "I was run by: $(whoami)"
echo "Today's date is: $(date)"

What does this script do?

#!/bin/bash tells Linux to use the Bash shell to run this script.
$(whoami) is a command substitution. Linux runs the command inside $() and inserts the result into the echo output.
$(date) does the same with today's date and time.

Save and exit nano by pressing Ctrl+X, then Y, then Enter.
Confirm the file was created by running:

ls

You should see hello.sh in the output.

Before you run this script, what do you think will happen? Will it print your greeting, or will something go wrong?

Try to run your script:

./hello.sh

You see bash: ./hello.sh: Permission denied. That is the designed obstacle for this step. Your instinct from Step 1 might be to reach for sudo, but this is YOUR file, not a system file.

Why is sudo not the answer here?

Using sudo to run your own scripts is like calling a locksmith when you just need to turn the lock. It works, but it gives your script full superuser powers it does not need.

The real problem is simpler. Linux created hello.sh without execute permission. You need to flip that lock open, not bypass the whole system.

Check the file's current permissions by running:

ls -l hello.sh

You should see something like -rw-r--r-- at the start of the line. This 10-character string is the permission string.

What does the permission string mean?

The 10 characters break into four groups, like reading a row of three doors:

- (character 1): file type. A - means regular file. A d means directory.
rw- (characters 2-4): the owner's permissions. Read and write, but no execute.
r-- (characters 5-7): the group's permissions. Read only.
r-- (characters 8-10): others' permissions (everyone else). Read only.

The missing x in the owner's section is exactly why ./hello.sh failed. Linux will not run a file unless the execute lock is open.

✔️ Awesome, I've got everything!

Make sure you have saved hello.sh and exited nano.

ⓧ I'd like to double check the full code

Your hello.sh should look exactly like this:

#!/bin/bash
echo "Hello from my script!"
echo "I was run by: $(whoami)"
echo "Today's date is: $(date)"

Fix permissions with chmod

Now that you can read the permission string, let's fix it. The chmod command changes file permissions. It supports two modes: symbolic (using letters) and numeric (using numbers).

Add execute permission for the owner by running this command:

chmod u+x hello.sh

What does chmod u+x mean?

u means "user" (the file's owner).
+ means "add."
x means "execute."

So chmod u+x hello.sh opens the execute lock for the file's owner.

Verify the permission changed by running:

ls -l hello.sh

You should now see -rwxr--r-- at the start. The x in the owner section means your script is now executable.

Do you think the script will work now? What do you expect to see?

Run your script again:

./hello.sh

You should see your greeting, your username, and today's date printed to the terminal. The execute lock is open and your script runs.

Still seeing Permission denied?

Make sure you ran chmod u+x hello.sh (not chmod x hello.sh). The u specifies who gets the permission.
Check that you are in the ~/level2-practice directory by running pwd.
Check your script's first line says #!/bin/bash with no extra spaces.

Why is my script still getting Permission denied after chmod?

Let's practice more symbolic changes. You can also add permissions to practice the round-trip of granting and revoking.

Add write permission for the group by running:

chmod g+w hello.sh

Verify the change by running:

ls -l hello.sh

You should see -rwxrw-r--. The w appeared in the group section. Group members can now modify your file.

Remove that group write permission by running:

chmod g-w hello.sh

Remove read permission from others by running:

chmod o-r hello.sh

Check the result of both changes by running:

ls -l hello.sh

You should see -rwxr-----. The group lost write and others lost read.

How does symbolic mode work?

The pattern is always: WHO, ACTION, PERMISSION.

Who: u (owner), g (group), o (others), a (all).
Action: + (add), - (remove), = (set exactly).
Permission: r (read), w (write), x (execute).

Symbolic mode is great for flipping one lock at a time. Numeric mode lets you set all three locks in one command.

What is numeric mode?

Numeric mode uses three digits to set all permissions at once. Each digit is a sum of: read (4) + write (2) + execute (1).

7 = read + write + execute (4+2+1).
5 = read + execute (4+1).
4 = read only.
0 = no permissions.

The three digits represent owner, group, and others in that order. So 755 means: owner gets rwx (7), group gets r-x (5), others get r-x (5).

Set hello.sh to 755 by running:

chmod 755 hello.sh

Verify the result by running:

ls -l hello.sh

You should see -rwxr-xr-x. That matches 755 exactly.

Try 644 to see a read-and-write-only setup by running:

chmod 644 hello.sh
ls -l hello.sh

You should see -rw-r--r--. The owner can read and write. Everyone else can only read.

Try 600 to lock the file down to only the owner by running:

chmod 600 hello.sh
ls -l hello.sh

You should see -rw-------. Only the owner can read and write. Nobody else has any access at all.

Set hello.sh back to 755 so it is executable again by running:

chmod 755 hello.sh

Why is 777 dangerous?

chmod 777 gives everyone full read, write, and execute access to your file. On a shared system, that means ANY user can modify or delete your script.

Always give the minimum permissions needed. If only you need to run a script, 700 is a much safer choice than 777.

Lock down secret.sh

Now put your permission skills to work. You will create a script that prints a secret message and lock it down so only you can read, write, and execute it.

Create secret.sh in nano by running:

nano secret.sh

Type the following script inside the nano editor:

#!/bin/bash
echo "This is a secret script!"
echo "Only $(whoami) can read and run this file."
echo "If you can see this output, you have the right permissions."

What does this script do?

This script prints a secret message and uses $(whoami) to display who is running it. After you lock it down, only your account will be able to see this output.

Save and exit nano by pressing Ctrl+X, then Y, then Enter.
Confirm both scripts exist by running:

ls

You should see both hello.sh and secret.sh in the output.

Lock down secret.sh to owner-only access by running:

chmod 700 secret.sh

What does 700 mean?

7 for the owner: read + write + execute (full access).
0 for the group: no access at all.
0 for others: no access at all.

This is the tightest useful permission. Only you can touch this file.

What do you think ls -l will show for the permission string now?

Verify the permissions by running:

ls -l secret.sh

You should see -rwx------ at the start of the line. Only you can read, write, and execute this file. Every other user on the system is completely locked out.

Run the script to confirm it works:

./secret.sh

You should see the secret message with your username printed. The permissions let you through because you are the owner.

Not seeing -rwx------?

Make sure you typed chmod 700 secret.sh (not chmod 700 hello.sh). Double-check the file name.
Run ls -l (without a file name) to see the permissions for all files in the directory.

Why are my file permissions not showing the right values?

✔️ Awesome, I've got everything!

Make sure you have saved secret.sh and that ls -l secret.sh shows -rwx------.

ⓧ I'd like to double check the full code

Your secret.sh should look exactly like this:

#!/bin/bash
echo "This is a secret script!"
echo "Only $(whoami) can read and run this file."
echo "If you can see this output, you have the right permissions."

Test your understanding

See how many of these you can answer from memory before moving on:

What do the three sections of a permission string (like -rwxr--r--) represent?
What does chmod u+x do, and when would you use it?
What numeric chmod value gives the owner full access and everyone else no access?
Why is setting a file to chmod 777 considered a bad practice?
If ls -l shows -rw-------, who can access this file and what can they do?

Your files are locked down exactly the way you want them. In the next step, you will create other users on your system and learn how to share files with them using groups.

Manage Users and Groups

In Step 2, you locked down secret.sh so only you can touch it. But you are the only user on your system right now. What happens when other people need access to your files?

Linux was built from the ground up for multiple users. Every user gets a numeric ID, belongs to one or more groups, and can share files with specific people through group permissions. In this step, you will create a practice user, switch between accounts, and set up a shared folder using groups.

In this step, get ready to:

Explore your own user identity with id and groups.
Create a practice user and switch between accounts.
Set up a shared folder using group permissions.

Explore your user identity

Every user on a Linux system has a numeric user ID (UID), a primary group ID (GID), and can belong to additional groups. Think of it like an employee badge that carries your ID number and lists which departments you belong to.

See your full identity by running this command:

id

You should see output like uid=1000(mint) gid=1000(mint) groups=1000(mint),24(cdrom),27(sudo)... with your own username instead of mint.

What does this output mean?

uid=1000(mint) is your user ID. The first regular user on a Linux system is usually UID 1000.
gid=1000(mint) is your primary group. Linux automatically creates a group with the same name as your user.
groups=... lists every group you belong to. The sudo group is the one that lets you run sudo commands.

Note your username from the output. You will need it later in this step when switching users:

Your username: your username from the id output

See a simpler list of just your group names by running:

groups

This prints the same groups as id but without the numeric IDs.

Peek at the system's user database by running:

cat /etc/passwd | tail -n 5

What is /etc/passwd?

Every user account on the system has an entry in /etc/passwd. Each line follows the format username:x:UID:GID:info:home:shell. The x means the password is stored elsewhere (in /etc/shadow, the file you accessed with sudo in Step 1).

The tail -n 5 part shows only the last 5 lines, so you see the most recently created users instead of the full list.

Create and switch to a practice user

So far you have been the only user on your system. Now you will create a second user called teammate to practice multi-user workflows.

What to expect from adduser

The adduser command is interactive. It will ask you to set a password (type it twice), then ask for optional info like Full Name and Room Number. Set a simple password you will remember, and press Enter to skip each optional field.

Create the practice user by running:

sudo adduser teammate

When prompted for a password, type a simple password you will remember (the characters will not appear on screen as you type).
Press Enter to skip each optional field (Full Name, Room Number, Work Phone, Home Phone, Other).
When asked Is the information correct?, type Y and press Enter.

You should see a confirmation that the user was added successfully.

Confirm the new user exists by checking the user database:

cat /etc/passwd | tail -n 3

You should see a teammate entry at or near the bottom of the list.

Before you switch, what do you think whoami will print once you are logged in as teammate?

Switch to the teammate account by running:

su - teammate

Being asked for a password?

The su command asks for the target user's password, not yours. Type the password you just set for teammate. The characters will not appear on screen as you type.

If you forgot the password, press Ctrl+C to cancel, then reset it with sudo passwd teammate. help me reset the teammate password

Confirm who you are now by running:

whoami

It prints teammate. You have switched to an entirely different user account.

Check your current location by running:

pwd

You should see /home/teammate. Every user gets their own home directory.

Return to your own account by typing:

exit

Your prompt changes back to your original username. You are back in your own account.

Set up shared access with groups

You can create users, but how do you share files with specific people without opening them up to everyone? Groups solve this. You add users to a group, then give that group access to a folder.

Create a new group called project-team by running:

sudo addgroup project-team

You should see a confirmation like Adding group 'project-team' (GID ...) ... Done.

Add yourself to the group by running:

sudo adduser $USER project-team

Add teammate to the group by running:

sudo adduser teammate project-team

Verify the group memberships by running:

groups teammate

You should see project-team listed in teammate's groups.

Why don't I see project-team in my own groups yet?

When you add yourself to a group, the change does not take effect in your current terminal session. You would need to log out and back in, or run newgrp project-team to activate it. For this exercise, that is fine. You own the shared folder, so you already have access as the owner.

Create a shared folder by running:

mkdir shared-folder

Confirm the folder exists by running:

ls

You should see shared-folder alongside hello.sh and secret.sh.

Change the folder's group ownership and set its permissions by running these two commands:

sudo chgrp project-team shared-folder
chmod 770 shared-folder

Verify the group and permissions by running:

ls -ld shared-folder

You should see something like drwxrwx--- 2 mint project-team ... shared-folder.

What does this permission string mean?

drwxrwx--- means the owner has full access (rwx), the group has full access (rwx), and everyone else has no access (---).
project-team in the output confirms the folder's group ownership was changed by chgrp.
Together, chgrp and chmod 770 mean only the owner and members of project-team can enter this folder.

Now you need to make sure teammate can actually walk through the directories leading to shared-folder. On many Linux systems, your home directory blocks other users from entering it. You need to add execute permission for others on each parent directory in the path.

Open up the path so teammate can traverse to the shared folder by running:

chmod o+x ~ ~/level2-practice

Why is this needed?

To reach shared-folder, teammate must pass through your home directory and level2-practice. The o+x permission lets others traverse (enter) a directory without being able to list or read its contents. Think of it like letting someone walk through your hallway to reach the shared meeting room, without letting them peek into the other rooms.

Time to test. Do you think teammate will be able to see inside shared-folder?

Switch to the teammate account by running:

su - teammate

Type the password you set for teammate when prompted.
Try listing the shared folder by running:

ls /home/[[YOUR_USERNAME="your username"]]/level2-practice/shared-folder

The folder is empty, so you should see no output and no errors. No error means teammate has access. If you saw Permission denied, the troubleshooting callout below can help.

Return to your own account by typing:

exit

Teammate got Permission denied?

Double-check that you ran chmod o+x ~ ~/level2-practice before switching to teammate. Without execute permission on the parent directories, teammate cannot traverse the path to reach shared-folder.

Also verify the folder's group with ls -ld shared-folder. It should show project-team as the group. help me troubleshoot teammate's Permission denied error on the shared folder

The sharing exercise is complete. Time to clean up the practice user and group so they do not stay on your system.

Remove the teammate user, the project-team group, and the shared folder by running these commands one at a time:

sudo deluser --remove-home teammate

sudo delgroup project-team

rm -r shared-folder

Verify the cleanup was successful by running:

cat /etc/passwd | grep teammate

No output means the teammate user is gone. If you see a line, the deletion did not work.

What did the cleanup commands do?

sudo deluser --remove-home teammate removed the user account and deleted their home directory at /home/teammate.
sudo delgroup project-team removed the group from the system.
rm -r shared-folder deleted the shared folder and anything inside it.

Seeing an error during cleanup?

If deluser says the user does not exist, you may have already removed them. If delgroup says the group is a primary group of a user, remove the user first with deluser before removing the group. help me fix cleanup errors with deluser and delgroup

✔️ Awesome, I've got everything!

Great. Your practice user and group are cleaned up, and hello.sh and secret.sh remain in ~/level2-practice with their original permissions.

ⓧ I'd like to double check what's left

Run this command to confirm the remaining files:

ls -l ~/level2-practice

You should see hello.sh with permissions -rwxr-xr-x and secret.sh with permissions -rwx------. No shared-folder should appear.

You now know how to create users, switch accounts, and share files with groups. Next up, you will learn to chain commands together with pipes and save output to files with redirection.

Use Pipes and Redirection

Every command you have run so far prints its output to the screen. Once you close the terminal or run the next command, that output is gone.

Pipes and redirection change that. In this step, you will learn to save command output to files, redirect error messages, and chain commands together into powerful multi-stage pipelines.

In this step, get ready to:

Redirect output to files using >, >>, and 2>.
Chain multiple commands together using pipes (|).
Split output to both screen and file using tee.

Redirect output to files

When you run a command like echo or cat, the output goes to your screen by default. Redirection lets you send that output to a file instead.

Write text to a new file by running this command:

echo "Hello Linux" > greeting.txt

Confirm the file was created by running:

cat greeting.txt

You should see Hello Linux printed to the screen.

What does > do?

The > operator redirects a command's output to a file. If the file does not exist, it creates one. If it already exists, it overwrites the contents completely.

Append a second line to the same file by running this command:

echo "Welcome back" >> greeting.txt

Check the file now by running:

cat greeting.txt

You should see both lines: Hello Linux on the first line and Welcome back on the second.

What is the difference between > and >>?

> overwrites the file with new content. >> adds to the end of the file without erasing what was already there. Think of > as "replace" and >> as "add more."

Accidentally overwrote your file?

If you used > instead of >> for the second line, the first line is gone. That is exactly how > works. Run the two commands again to rebuild the file:

echo "Hello Linux" > greeting.txt
echo "Welcome back" >> greeting.txt

Help me understand the difference between > and >> in Linux.

Commands can produce two kinds of output. Regular output (called stdout) is what you have been redirecting so far. Error messages (called stderr) are a separate stream.

Redirect an error message to a file by running this command:

cat /etc/shadow 2> errors.txt

Nothing appears on screen. The error message was captured and sent to the file instead.

Check what was captured by running:

cat errors.txt

You should see a "Permission denied" message inside the file. This is the same error you saw in Step 1, but now it is saved to disk instead of flashing by on screen.

What does 2> do?

2> redirects stderr (error output) to a file. The 2 refers to file descriptor 2, which Linux uses for error messages.

Regular output uses file descriptor 1, which is what > redirects by default. Separating these streams lets you save errors to a log file while keeping normal output clean.

Chain commands with pipes

A pipe (|) takes the output of one command and feeds it directly into the next command as input. Instead of saving intermediate results to files, you chain commands together in a single line.

Filter your file listing to show only shell scripts by running this command:

ls -la | grep ".sh"

You should see only the files ending in .sh listed. The pipe sent the full output of ls -la into grep, which filtered it down to matching lines.

What does the pipe do here?

ls -la lists all files with details. The | (pipe) takes that entire list and sends it to grep ".sh", which only shows lines containing .sh. You get a filtered view without creating any intermediate files.

Sort the system's user list and show only the first 5 entries by running this command:

cat /etc/passwd | sort | head -n 5

You should see five lines of user entries, sorted alphabetically.

What happens at each stage of this pipe?

cat /etc/passwd reads the full user database.
sort arranges the lines alphabetically.
head -n 5 keeps only the first five lines and discards the rest.

Each | passes the result of one command into the next, like an assembly line.

Count how many shell script files you have by running this command:

ls -l | grep ".sh" | wc -l

You should see the number 2. That counts hello.sh and secret.sh.

What does wc -l do?

wc -l counts the number of lines in its input. Piped after grep, it counts how many lines matched the filter. This turns a file listing into a single number.

Save output with tee and build a full pipeline

Sometimes you want to save output to a file AND see it on screen at the same time. The tee command does exactly that. It sits in the middle of a pipe, writing everything to a file while passing it along to the screen.

Save your file listing to a file while displaying it on screen by running this command:

ls -la | tee filelist.txt

You should see the full file listing on screen, just like a normal ls -la.

Confirm the same output was saved to the file by running:

cat filelist.txt

You should see the same listing inside filelist.txt. The output went to both places at once.

What does tee do?

tee is named after a T-shaped pipe fitting. It splits the flow of data: one copy goes to the file you name, and the other continues to the screen (or to the next command in the pipe).

This is useful when you want to monitor output in real time while also keeping a saved record.

Now combine everything you have learned. You will build a pipe chain that processes data through multiple stages, then redirect the final result to a file.

Sort and deduplicate the user database, then save the result to a file by running this command:

cat /etc/passwd | sort | uniq > combined.txt

No output appears on screen because > redirected everything to combined.txt.

What does this pipeline do?

cat /etc/passwd reads the raw user database.
sort arranges all lines alphabetically.
uniq removes any consecutive duplicate lines.
> combined.txt saves the final result to a file instead of printing it to screen.

This is three commands and a redirect working together in one line. Each stage transforms the data before passing it on.

Before you check the file, what do you expect to see inside combined.txt?

Check the result by running this command:

cat ~/level2-practice/combined.txt

You should see a sorted list of user entries from /etc/passwd, with no duplicate lines. This is the result of three commands chained together and redirected to a file.

Not seeing sorted output?

Make sure you ran the full command cat /etc/passwd | sort | uniq > combined.txt on a single line. If you split it across lines, the pipe chain breaks.
If combined.txt is empty, check that you typed > and not 2>. The > operator redirects regular output. The 2> operator only captures errors.

My combined.txt file is empty or has unexpected content. What went wrong?

You have four powerful tools in your belt now: sudo, permissions, user management, and pipes. In the next step, you will combine them all to build a real admin toolkit from scratch.

Build the Admin Toolkit

In the last step, you learned to chain commands with pipes and save output with redirection. You now have four separate skills in your toolkit: sudo, permissions, user management, and pipes.

Can you bring them all together to build something real? In this step, you'll prove it by creating a complete admin toolkit with a custom script, locked-down permissions, a saved report, and shared access for a teammate.

In this step, get ready to:

Write a system info script that reports your username, date, and top processes.
Lock the script with owner-only permissions and generate a saved report file.
Share the toolkit with a practice user through group permissions, then clean up.

Create the admin-toolkit folder and write sysinfo.sh

Your admin toolkit needs its own folder to keep everything organized. You'll create the folder, then write a Bash script inside it that collects system information.

Create your admin-toolkit folder and move into it by running these commands:

mkdir admin-toolkit
cd admin-toolkit

Confirm you're in the right place by running:

pwd

You should see /home/ followed by your username, ending in /level2-practice/admin-toolkit.

Open a new file called sysinfo.sh in nano by running:

nano sysinfo.sh

Type the following script into the nano editor:

#!/bin/bash
echo "=============================="
echo "  SYSTEM INFORMATION REPORT"
echo "=============================="
echo ""
echo "Report generated: $(date)"
echo "Current user: $(whoami)"
echo ""
echo "--- Top 10 Running Processes ---"
ps aux | head -n 11
echo ""
echo "=============================="
echo "  END OF REPORT"
echo "=============================="

What does this script do?

The first line #!/bin/bash tells Linux to use Bash to run this script.

The echo lines with = signs print a visual header and footer so the report looks tidy.
$(date) and $(whoami) are command substitutions. Bash runs the command inside $(...) and inserts its output into the echo string.
ps aux | head -n 11 lists all running processes, then pipes the result to head which keeps only the first 11 lines. That gives you the header line plus the top 10 processes.

Save and exit nano by pressing Ctrl+O, then Enter, then Ctrl+X.
Run your new script by running:

bash sysinfo.sh

You should see your formatted report printed on screen, including today's date, your username, and a list of running processes.

Don't see any output?

Make sure you saved the file in nano before exiting. Press Ctrl+O to save, then Ctrl+X to exit.
Check you're in the admin-toolkit folder by running pwd. If not, navigate there with cd ~/level2-practice/admin-toolkit.
If you see a syntax error, open the file with nano sysinfo.sh and double-check each line matches the script above exactly.

Still stuck? Help me debug my sysinfo.sh script that won't run.

✔️ Awesome, I've got everything!

Great. Double check you've saved sysinfo.sh and the output looks right.

ⓧ I'd like to double check the full code

Here is the complete sysinfo.sh script. Compare it line by line with yours:

#!/bin/bash
echo "=============================="
echo "  SYSTEM INFORMATION REPORT"
echo "=============================="
echo ""
echo "Report generated: $(date)"
echo "Current user: $(whoami)"
echo ""
echo "--- Top 10 Running Processes ---"
ps aux | head -n 11
echo ""
echo "=============================="
echo "  END OF REPORT"
echo "=============================="

Lock down permissions and generate a report

Your script works, but right now anyone on the system could read or modify it. You'll lock it down to owner-only access, then use redirection to save the output to a report file.

Set the script to owner-only permissions by running:

chmod 700 sysinfo.sh

Verify the permissions changed by running:

ls -l sysinfo.sh

You should see -rwx------ at the start of the line. That means only you (the owner) can read, write, and execute this file. Nobody else can touch it.

What does -rwx------ mean?

rwx (positions 2-4): the owner can read, write, and execute.
--- (positions 5-7): the group has no permissions at all.
--- (positions 8-10): others have no permissions at all.

The numeric equivalent is 700: 7 (read + write + execute) for the owner, 0 for group, 0 for others.

Now put your redirection skills to work. Before you run the next command, predict: what do you think > will do to the script's output?

Run your script again and redirect the output to a report file:

bash sysinfo.sh > report.txt

Nothing appears on screen this time. The > operator sent all the output into report.txt instead.

Read the saved report by running:

cat report.txt

You should see the same system information report you saw on screen earlier, now saved permanently in a file.

report.txt is empty?

Make sure you typed bash sysinfo.sh > report.txt with a single >, not >>. Both work, but if the file was empty before, either will produce the same result.
Check that sysinfo.sh still runs correctly on its own with bash sysinfo.sh. If that produces no output, the script file may have been accidentally overwritten.

Still stuck? Help me figure out why my report.txt is empty.

Share the toolkit with a teammate

Your toolkit is locked down to you alone. In a real team, you'd need to share access with specific people without opening it to everyone.

You'll create a practice user, set up a shared group, and use group permissions to give your teammate read access to the report.

Create a practice user called teammate by running:

sudo adduser teammate

What will adduser ask me?

The command will prompt you to set a password for teammate. Type a simple practice password (the characters won't appear on screen, that's normal). You'll type it twice to confirm.

Next it asks for optional details like Full Name, Room Number, and phone numbers. Press Enter to skip each one. When it asks Is the information correct?, type Y and press Enter.

Create a shared group and add both users to it by running these commands one at a time:

sudo addgroup toolkit-team

sudo adduser $USER toolkit-team
sudo adduser teammate toolkit-team

Verify both users are in the group by running:

grep toolkit-team /etc/group

You should see a line that includes both your username and teammate after toolkit-team.

Group changes and your current session

Adding yourself to a group with adduser does not take effect in your current terminal session. You would need to log out and back in, or run newgrp toolkit-team, for your shell to recognize the new membership.

This does not affect the commands below because you'll use sudo for the group ownership change. And when you switch to teammate with su, that starts a fresh login session where group membership is already active.

Change the group ownership of the admin-toolkit folder by running:

sudo chgrp -R toolkit-team ~/level2-practice/admin-toolkit

Set the folder permissions to 750 so the owner gets full access and the group gets read and execute access:

chmod 750 ~/level2-practice/admin-toolkit

Verify the folder's group and permissions by running:

ls -ld ~/level2-practice/admin-toolkit

You should see drwxr-x--- with toolkit-team listed as the group.

Now for the real test. Switch to the teammate account and see if they can read the report.

Switch to the teammate user by running:

su - teammate

Which password do I type?

The su command asks for the target user's password, not yours. Type the password you set for teammate when you ran adduser. The characters won't appear on screen as you type.

Confirm you are now teammate by running:

whoami

You should see teammate printed.

Try reading the report by running:

cat ~/level2-practice/admin-toolkit/report.txt

You should see the full system information report. The teammate user can read the file because they belong to the toolkit-team group, and the folder's group permissions include read access.

Switch back to your own account by running:

exit

Your prompt returns to your normal username. Time to clean up the practice user and group.

Remove the teammate user and their home directory by running:

sudo deluser --remove-home teammate

Remove the shared group by running:

sudo delgroup toolkit-team

Each command prints a confirmation message when it finishes.

Seeing an error during cleanup?

If deluser says the user is currently logged in, make sure you typed exit to leave the teammate session first. You must be back on your own account.
If delgroup says the group is a primary group for a user, delete the user first with deluser, then try delgroup again.

Still stuck? Help me clean up my practice user and group on Linux.

Before you look at the final result, predict: is report.txt still in the admin-toolkit folder after deleting the user and group?

Check for yourself by running:

cat ~/level2-practice/admin-toolkit/report.txt

The report is still there. Deleting a user or group does not delete the files they had access to. Your admin toolkit is complete.

A common Linux error you might see independently

If you ever see Unable to lock the administration directory while running a command with sudo, it usually means another program (like an automatic updater) is already using the package manager. Wait a minute and try again.

Secret mission

The File Type Census

Ready for one more challenge? Build a census.sh script that counts every file type in your level2-practice directory. You will use pipes, command substitution, and the find command to scan your workspace and generate a census report.

Clean Up Your Resources

This project runs entirely locally using built-in Linux tools, so there are no ongoing costs. Decide whether to keep your files for reference, partially clean up, or remove everything.

Resources you used:

~/level2-practice directory containing all project files (scripts, reports, practice output files, and test files).
Practice user teammate (should have been removed during Steps 3 and 5).

Keep everything running

No action needed. Choose this if you want to keep practicing Linux commands or revisiting the scripts you wrote.

Your ~/level2-practice folder stays on your machine with all scripts and reports intact.
You can re-run your scripts anytime with bash sysinfo.sh or bash census.sh from inside admin-toolkit.
Since everything is local, there are no costs for keeping these files.

Pause - I'll come back to this later

Remove generated output and practice files but keep your scripts for future reference.

Delete the practice text files and log files from ~/level2-practice by running:

rm ~/level2-practice/*.txt ~/level2-practice/*.log

This removes greeting.txt, errors.txt, filelist.txt, combined.txt, and any test files while keeping your shell scripts.
Your admin-toolkit folder stays intact with sysinfo.sh, census.sh, and both report files.

Delete - I don't want to use this again

Remove all project files and start fresh.

Delete the entire practice directory by running:

rm -r ~/level2-practice

Verify the practice user teammate was removed during the project by running:

id teammate

If you see user information instead of an error, the user was not cleaned up. Remove it by running:

sudo deluser --remove-home teammate

Confirm the directory is gone by running:

ls ~/level2-practice

You should see an error message confirming the directory no longer exists.

Nice Work!

You just took control of your Linux system. You built a complete admin toolkit from scratch, locked it down with permissions, shared it with another user, and generated reports using pipes and redirection.

You learned how to:

Use sudo for temporary superuser access, read file permission strings from ls -l, and change permissions with both symbolic mode (u+x, g-w) and numeric mode (755, 700).
Create and remove users and groups with adduser, deluser, addgroup, and chgrp, and set up shared folders with group permissions.
Chain commands with pipes (|), redirect output to files (>, >>), and build a complete admin-toolkit with a custom sysinfo.sh script, owner-only permissions, and a generated report.txt.
Secret Mission: Created a census.sh script that counts file types in a directory using pipes and command substitution.

Ready to quiz yourself?