Learn › RHCSA (EX200) › Exam Orientation + Essential Tools
ln - a hands-on Linux lab on a real virtual machine.
Create hard and soft links for EX200 task 3. A hard link is a second name on the same inode; a symlink is a small file that points at a path. Read inode and link count with ls -li, confirm a target with readlink, and know which type crosses filesystems and points at directories.
You copy a file and now you have two files: two copies of the data, taking up twice the room, drifting apart the moment you edit one. That is often not what you want. Sometimes you want two NAMES that reach the SAME file, so a change through one name is a change to the other, because there is only one file underneath.
That is what a link is. On the RHCSA exam this is task 3, stated plainly: create hard and soft links. It sounds like one skill. It is two, and they behave differently enough that handing in the wrong one scores zero. This lesson teaches you to build both, tell them apart at a glance, and know which to reach for.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. You cannot break anything. The outputs are one real capture from a RHEL 10 machine. Inode numbers and dates are that machine's own, so yours will read differently. The SHAPE is what you learn, and the shape is the same everywhere.
Every file on a Linux disk has an inode: a numbered record the filesystem keeps for that file. The inode holds the file's real data location, its size, its permissions, and a count of how many names point at it. The name you see in a folder is just a label pinned to an inode. The inode is the file. The name is a handle.
That one fact splits links into two kinds.
A hard link is a second name pinned to the SAME inode. Two names, one inode, one file. Change the file through either name and you change the one file, because there is only one.
A soft link, also called a symbolic link or symlink, is a tiny separate file with its OWN inode whose entire contents are a path to another file. It does not share the data. It points at a name. Think of a hard link as a second nameplate on the same door, and a symlink as a sticky note that says go to that other door.
The tool for both jobs is ln, short for link. With no flag it makes a hard link. The order is always ln target linkname: the file that already exists first, the new name second.
Assume a file report.txt already sits in your home directory. Give it a second name, hard.txt, pinned to the same inode:
ln report.txt hard.txt
prompt: student@servera:~$ answer: ln report.txt hard.txt output: hint: The command is ln, then the existing file, then the new name. No flag for a hard link: ln report.txt hard.txt
ln prints nothing on success, which is normal for Unix tools: silence means it worked. There is now a second name, hard.txt, hanging off the very same inode as report.txt. Neither name is the original in any meaningful sense. They are equal handles on one file. Delete either name and the file lives on under the other, because a file is only truly gone when its LAST name is removed. Next you prove they share an inode.
To see the proof, add -i to ls. The -i flag prints each file's inode number as the first column. The long listing from -l shows the link count: the number just after the permission bits, which is how many names point at that inode. Combine them as ls -li.
List both names and read the two columns that matter:
ls -li report.txt hard.txt
prompt: student@servera:~$ answer: ls -li report.txt hard.txt output: 393276 -rw-r--r--. 2 student student 20 Jul 5 18:36 hard.txt 393276 -rw-r--r--. 2 student student 20 Jul 5 18:36 report.txt hint: Same ls, but add the i flag to -l so it shows inode numbers: ls -li report.txt hard.txt
Read the two clues. Both lines start with the SAME inode number, 393276, so both names reach one file. And the count right after the permissions is 2, telling you two names now point at that inode. Your machine's inode number will not be 393276, and the date will differ. What holds everywhere is the pattern: matching inode, link count of 2.
A symlink is the other tool in ln, unlocked by the -s flag (s for symbolic). Same argument order: ln -s target linkname. The difference is what gets made. Instead of a second name on the same inode, you get a brand new little file whose contents are the path report.txt.
Point a symlink named soft.txt at report.txt:
ln -s report.txt soft.txt
prompt: student@servera:~$ answer: ln -s report.txt soft.txt output: hint: This time add the -s flag before the target and link name: ln -s report.txt soft.txt
Silent again, so it worked. But this created something structurally different from the hard link. soft.txt is its own file with its own inode, and all it holds is the text report.txt, the path it points at. Follow the link and the system reads that path and hands you report.txt. That indirection is the symlink's whole nature, and it is why a symlink can do two things a hard link cannot, as you will see. First, look at how differently it lists.
Run ls -li again, now including soft.txt. Two tells mark a symlink and nothing else does. The permission string begins with the letter l for link, not the - of a regular file. And the name is followed by an arrow, ->, then the path it targets. That arrow is a symlink announcing exactly where it sends you.
List all three names together:
ls -li report.txt hard.txt soft.txt
prompt: student@servera:~$ answer: ls -li report.txt hard.txt soft.txt output: 393276 -rw-r--r--. 2 student student 20 Jul 5 18:36 hard.txt 393276 -rw-r--r--. 2 student student 20 Jul 5 18:36 report.txt 917476 lrwxrwxrwx. 1 student student 10 Jul 5 18:36 soft.txt -> report.txt hint: The same ls -li, now with all three names listed: ls -li report.txt hard.txt soft.txt
Look at how soft.txt stands apart. Its inode 917476 is DIFFERENT from the 393276 the other two share, so it is a separate file. Its type is lrwxrwxrwx, starting with l. Its link count is 1, not 2, because nothing else points at it. And it ends in -> report.txt, naming its target out loud. Your inode numbers and date will differ, but every one of those tells appears on any machine.
Two more tools finish the picture, and both show up on the exam. readlink prints only the path a symlink points at, nothing else, which is the fastest way to ask where does this link go. And stat prints a file's full inode record, including a Links: field that is the same link count you read in ls -li, spelled out.
Ask readlink where soft.txt sends you:
readlink soft.txt
prompt: student@servera:~$ answer: readlink soft.txt output: report.txt hint: The tool is readlink, then the symlink's name: readlink soft.txt
readlink answered with the bare target path, report.txt, and nothing more. That is its whole job: no listing, no permissions, just the destination stored inside the link. When a task asks you to confirm a symlink points where it should, readlink linkname is the one-word answer. stat report.txt would tell you the same story from the other side, printing Links: 2 for the hard-linked file, matching the count you already read. Both are honest ways to check your work before you move on.
Scaffolding off. No command is printed this time. You have every piece.
A file named report.txt exists. You want a SECOND NAME for it that reaches the exact same file. Editing through either name should edit the one underlying file, and the file should survive even if the original name is deleted. You do not want a separate pointer file. You want another true name on the same inode.
prompt: student@servera:~$ answer: ln report.txt hard.txt output: hint: A second name on the same inode is a HARD link, so no -s flag. Think ln, the existing file, then the new name.
That is the move the grader rewards when it says hard link. No -s, because -s would have built a symlink with its own inode, and that is the wrong answer to a hard-link question. Plain ln target linkname pinned a new name to the same inode as report.txt, raising its link count to 2. Confirm any hard link the same way every time: ls -li shows a shared inode number and a link count above 1. You chose the form from memory, which is exactly what exam task 3 asks of you.
You earned this cheat sheet. Every row is something you just ran or read:
And the difference that decides which to use:
When a hard link fails with Invalid cross-device link, the target is on a different filesystem, and a hard link cannot span two filesystems because inode numbers are only unique within one. When it fails with Operation not permitted on a folder, you tried to hard-link a directory, which is not allowed. Both cases have the same fix: use ln -s. A symlink can cross filesystems and can point at a directory, which is exactly why it exists.
The practice terminal has shown you the whole of task 3. You built a hard link with ln, built a symlink with ln -s, read a shared inode and link count with ls -li, and confirmed a target with readlink. Every one of those you typed yourself, and the challenge made you pick the right form with no command in front of you.
The Essential Tools module ends on one real RHEL 10 machine, the essential-tools capstone mission, and that is where you create links for real. It boots for you with its own disk and its own inode numbers, and it hands you objectives drawn from everything in this module. One difference from here: the mission shows no commands. You read the objective, recall the command, and type it, because that recall is what the real exam measures.
Finish the other Essential Tools lessons, then go link files for yourself.
Practice Hard and Soft Links in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.