Hard Links vs Symbolic Links in Linux: Inodes, Paths, and the ln Command

🧠 The Mental Model: A Filename Is Not the File

Start with a common assumption: a filename is the file itself.

Linux filesystems work differently. In a typical Unix-style filesystem, a directory contains entries that associate names with inode numbers. An inode represents a filesystem object and records information such as its type, permissions, ownership, timestamps, and references to its data.

The name is part of a directory entry. It is not normally stored as the filename inside the inode.

For example, when you open /home/alex/report.txt, Linux resolves the components of that pathname through the filesystem until it reaches the object associated with the final name.

Understanding this distinction is an important next step after learning the Linux filesystem directory structure.

Both link types help users reach files through different names. However, their relationships to the underlying objects are fundamentally different.

💎 What Is an Inode in Linux?

An inode is a filesystem data structure used to represent a file or another filesystem object.

On common Linux filesystems, inode metadata includes information such as:

• file type;
• owner and group identifiers;
• permission bits;
• file size;
• timestamps;
• hard-link count;
• information needed to locate the file’s data.

Inode numbers are meaningful within a filesystem. Two different filesystems can use the same inode number for unrelated objects.

This is one reason inode numbers should not be interpreted without their filesystem or device context.

How to See an Inode Number

The ls -i command displays inode numbers alongside filenames.

ls -i

The numbers depend on your filesystem and will differ between systems.

You can also inspect a specific object’s inode and hard-link count with GNU stat:

stat -c 'Inode: %i | Links: %h | Name: %n' /etc/hosts

The %i field displays the inode number. The %h field shows how many hard links refer to that object.

Inodes are part of the broader storage model. To understand how filesystems relate to partitions and mount points, see Linux Storage Explained.

🔗 How Hard Links Work in Linux

A hard link creates another name for an existing filesystem object.

When you create a hard link to a regular file, Linux adds another directory entry referring to the same inode.

It does not create a separate copy of the file’s contents.

Suppose a file named report.txt already exists. You can create another name for it with:

ln report.txt alias.txt

Both names now identify the same underlying file. Reading either name accesses the same contents, and modifications made through either name affect that shared object.

Hard Links Are Not Backups

Imagine that both filenames contain the text Production settings.

If a program overwrites the file through alias.txt, opening report.txt shows the changed data too.

Both names refer to the same file object, so there are not two independent copies to recover from.

What Happens When a Hard Link Is Removed?

Removing one hard-linked filename removes that directory entry and decreases the inode’s link count.

If another hard link still exists, the file remains accessible through that other name.

When the final hard link is removed, the filesystem can reclaim the object once no remaining references, such as open file descriptors, require it.

This behavior explains why removing a filename does not always immediately release all storage used by the underlying file.

🧭 How Symbolic Links Work in Linux

A symbolic link works through a pathname rather than a direct shared-inode relationship.

Unlike a hard link, a symlink is a separate filesystem object. It stores a string representing a path to another object.

For example:

ln -s report.txt shortcut.txt

Here, shortcut.txt is a symbolic link containing the relative pathname report.txt.

When a program opens shortcut.txt, Linux normally follows that pathname and attempts to open the target.

If report.txt no longer exists at the expected location, the symlink may become broken.

Why Symbolic Links Can Break

Suppose you rename report.txt to report-old.txt.

The symbolic link still contains the original pathname. Linux does not automatically rewrite that stored string.

Consequently, opening the link may fail because the pathname no longer resolves.

The symbolic link itself still exists. Its target simply cannot be found through the stored path.

Relative vs Absolute Symbolic Links

Symbolic links can store either relative or absolute paths.

Relative links can remain valid when a complete directory tree is moved without changing the internal relationship between its files.

Absolute links can be useful when the target has a stable system-wide location, but they may break if that location changes.

Neither approach is universally better. The correct choice depends on where the symlink will be stored and how the target path is expected to change.

⚖️ Hard Links vs Symbolic Links: Key Differences

The following comparison summarizes the practical differences between the two link types on typical Linux filesystems.

When comparing hard links vs symbolic links, remember that neither creates an independent backup. Their purpose is to provide different ways of referring to filesystem objects.

🗄️ Why Hard Links Cannot Cross Filesystems

A hard link must refer to an inode within the same filesystem.

Inode numbers are not globally unique across Linux. They are interpreted together with the filesystem or device containing them.

A directory entry on one filesystem cannot simply establish an ordinary hard-link relationship with an inode belonging to another filesystem.

A symbolic link is different. Because it stores a pathname, that path can resolve to an object located on another mounted filesystem.

For example, a symlink in your home directory might refer to a file stored on a separate mounted data volume.

Whether opening it succeeds depends on the target path being reachable and the necessary permissions being available.

🔐 Do Hard Links and Symbolic Links Have Different Permissions?

Hard links share the same inode, so they share the file’s ownership, permission bits, and other inode-level metadata.

Changing the permissions through one hard-linked filename changes the permissions observed through the other.

Symbolic links have their own metadata, but on Linux the symlink’s permission bits are generally not used to authorize ordinary access to the target.

When a program follows a symbolic link, access checks apply to the target and the directories involved in resolving its path.

Creating a symbolic link therefore does not bypass the permissions of the target file.

For a fuller explanation of ownership and access checks, read Linux File Permissions Explained.

🔎 How to Inspect Links with ls, stat, and readlink

Linux provides several commands for examining file links without modifying them.

For more on file discovery and search conditions, see Linux find Command Explained.

🧪 Mini Lab: Create and Compare Both Link Types

This experiment demonstrates the difference between hard links and symbolic links without changing system configuration.

It uses a temporary directory and ordinary files. No administrator privileges are required.

Step 1: Create a Temporary Workspace

lab_dir="$(mktemp -d)"

printf 'Linux link experiment\n' > "$lab_dir/original.txt"

printf 'Workspace: %s\n' "$lab_dir"

The mktemp -d command creates a new temporary directory. Save the reported path if you want to inspect the files manually afterward.

Step 2: Create a Hard Link

ln "$lab_dir/original.txt" "$lab_dir/alias.txt"

The new filename alias.txt refers to the same inode as original.txt.

Step 3: Create a Symbolic Link

ln -s original.txt "$lab_dir/shortcut.txt"

Here the symbolic link stores the relative path original.txt. That path is interpreted relative to the directory containing shortcut.txt.

Step 4: Inspect the Inodes

ls -li "$lab_dir"

stat -c '%n | inode=%i | links=%h' \
  "$lab_dir/original.txt" \
  "$lab_dir/alias.txt" \
  "$lab_dir/shortcut.txt"

Look for three observations:

• original.txt and alias.txt have the same inode number.
• The shared regular file normally has a hard-link count of 2.
• shortcut.txt has its own inode because it is a separate symbolic-link object.

GNU stat normally inspects the symbolic link itself unless you request target dereferencing with -L.

Step 5: Inspect the Stored Symlink Path

readlink "$lab_dir/shortcut.txt"

The expected output is:

original.txt

This is the pathname stored in the symlink, not the inode number of the target.

Step 6: Rename the Original Filename

mv "$lab_dir/original.txt" "$lab_dir/renamed.txt"

The file object has not been replaced. Only one directory entry’s name has changed.

Now read the contents through the hard link:

cat "$lab_dir/alias.txt"

You should still see:

Linux link experiment

The hard link remains valid because it still refers to the same inode.

Step 7: Check the Symbolic Link

if [ -L "$lab_dir/shortcut.txt" ]; then
  printf 'The symbolic link still exists.\n'
fi

if [ -e "$lab_dir/shortcut.txt" ]; then
  printf 'Its target resolves.\n'
else
  printf 'Its target no longer resolves.\n'
fi

The symbolic link still exists, but its stored pathname still says original.txt.

Since that pathname no longer identifies the renamed file, the link is dangling.

Notice the distinction: test -L checks whether the object is a symbolic link, while test -e follows the link when checking whether its target exists.

Step 8: Find Names That Share the Same File

find "$lab_dir" -maxdepth 1 -type f \
  -samefile "$lab_dir/alias.txt"

The expected matches are alias.txt and renamed.txt.

The -samefile predicate checks filesystem identity rather than merely comparing filenames or file contents.

Step 9: Clean Up the Lab

Before deleting anything, display the temporary workspace path and verify that it is the directory created for this experiment.

printf 'Lab directory: %s\n' "$lab_dir"

ls -la "$lab_dir"

Once you have confirmed the path, remove only the three files created in the lab and then the now-empty directory:

if [ -n "$lab_dir" ] && [ -d "$lab_dir" ]; then
  rm -- "$lab_dir/shortcut.txt" \
        "$lab_dir/alias.txt" \
        "$lab_dir/renamed.txt"

  rmdir -- "$lab_dir"
fi

These commands assume the earlier steps completed successfully. Run them only after checking the temporary path. No recursive deletion is required.

⚠️ Common Mistakes with Linux Links

🧩 When Should You Use a Hard Link or a Symbolic Link?

The better choice depends on what relationship you want to preserve.

Use a Hard Link When…

• You need another filename for the same regular file.
• Both names are located on the same filesystem.
• You want access through one name to remain valid if another name is removed.
• You understand that both names share the same data and metadata.

Use a Symbolic Link When…

• You want a convenient alias for a file or directory.
• The target may be located on another filesystem.
• You intentionally want the link to represent a particular pathname.
• You need a stable public path that can be redirected to a different versioned directory or file.

A common server example is a deployment directory:

/srv/application/
├── releases/
│   ├── release-a/
│   └── release-b/
└── current -> releases/release-b/

Here, current is a symbolic link to a release directory. Applications can refer to one stable pathname while administrators manage versioned directories behind it.

This is an example of deliberate pathname indirection. It would not normally be implemented with a hard link because ordinary hard links to directories are prohibited.

🧠 Knowledge Check

Test your understanding of the relationship between names, inodes, and filesystem objects.

📚 Official References

The following primary technical sources explain Linux inode metadata, symbolic-link behavior, and the GNU tools used in this lesson.