What is a Hard Link in Linux : How It Differs from a Soft Link

Trying to create a hard link and getting an invalid cross-device link error usually means the command is fine, but the filesystem layout is not. The same issue shows up when people expect a hard link to behave like a copy, or when they confuse it with a symbolic link and then break file workflows after a rename or delete.

Core idea	Multiple names, one inode, one set of file data
Link target	File data through the inode, not the pathname
Cross-filesystem support	No; hard links must stay on the same filesystem as of August 2026
Directory support	Generally restricted for regular users and standard workflows as of August 2026
Best verification tools	ls -li and stat as of August 2026
Common error	Invalid cross-device link when source and destination are on different mounts as of August 2026
Typical use	Local file management, retention, and stable references to the same content

What Is a Hard Link in Linux?

A hard link is a second name for the same file content. Linux does not treat the filename as the file itself; it treats the inode as the identity of the file, and the directory entry is just the label that points to it.

This matters because a file can have more than one name without using extra disk space for duplicate data. If you create a hard link to report.txt and then edit either name, you are editing the same inode, so both names show the same updated content.

Why Linux Uses Inodes, Not Filenames

Inode-based storage is the reason Linux can separate identity from naming. A filename lives in a directory; the inode stores metadata such as ownership, permissions, timestamps, and pointers to data blocks.

That design gives Linux flexibility. A file can be renamed, linked from multiple places, or deleted from one path while still existing through another hard link. The data stays alive until the last link to that inode disappears.

“A hard link is not a copy. It is another doorway into the same room.”

A simple analogy helps: think of a book in a library catalog. The catalog card is the filename, while the physical book is the inode-backed content. Two catalog cards can point to the same book, and removing one card does not destroy the book.

Why This Matters in Daily Work

Hard links affect how you edit files, how much storage you use, and how deletion behaves. If a log file, release artifact, or configuration file has multiple hard links, deleting one path does not remove the data until the last name is gone.

• File edits apply to all hard-linked names because they share the same inode.
• Storage use stays low because the data blocks are not duplicated.
• Deletion behavior is safer in one sense and riskier in another, because removing one name may not free space immediately.

If you are troubleshooting Linux file behavior, hard links are one of the first things to check. They explain many “why didn’t deleting this file actually remove it?” moments.

How Hard Links Work Under the Hood

Hard links work by increasing the reference count on an inode. Every time you create another hard link, you add another directory entry that points to the same underlying file data.

1. The original file is created in a directory.
2. Linux assigns it an inode number.
3. You create a hard link with ln existing-file new-name.
4. The new filename points to the same inode.
5. The inode’s link count increases by one.

That link count is critical. It tells the filesystem how many names still reference the same data. When the count reaches zero, the inode and its data blocks can finally be reclaimed.

What Changes When You Edit One Name

When you modify one hard-linked name, you are modifying the same file data seen by every other link. There is no hidden second copy. The change is shared because the file is stored once and referenced many times.

That is why hard links are useful for preserving a stable reference to the same content. They are also why hard links can surprise people who expect “different filenames” to mean “different files.”

How to Inspect Inodes and Link Counts

Use ls -li when you want a quick check. The inode number appears in the first numeric field, and the link count appears next to the permissions and ownership information.

ls -li file1 file2

Use stat when you want a more precise view of inode metadata.

stat file1

Look for the same inode number on both names and a link count greater than 1. If those numbers match, you are not looking at two copies; you are looking at the same underlying file through different names.

According to the Linux link(2) manual, hard links are created at the filesystem level and are constrained by that filesystem’s boundaries. For practical command-line work, that single rule explains most hard link surprises.

Hard Link vs Soft Link: The Core Differences

A symbolic link is a special file that stores a path to another file or directory, while a hard link points directly to the inode. That is the key difference, and it drives almost every behavior people notice in real use.

Hard link	Points to the same inode and same file data
Soft link	Points to a path, not the data itself
If original name is deleted	Hard link still works if another link remains
If target is deleted	Symlink can break and point nowhere

That difference explains why hard links survive renames and deletions more gracefully. As long as at least one name still exists, the inode stays alive. A symlink, by contrast, depends on the target path remaining valid.

Path Behavior vs Inode Behavior

A hard link does not care what the file was called originally. A symbolic link does. If the target path changes, the symlink may become broken even though the linked file once existed.

This is why administrators often prefer hard links for local file retention and symlinks for flexible path redirection. The choice comes down to whether you want identity or indirection.

What Happens After Rename, Move, or Delete

• Rename: A hard link keeps working because it points to the inode, not the old name.
• Move within the same filesystem: A hard link still works if the inode remains on the same filesystem.
• Delete one name: The hard link survives if another name still points to the inode.
• Delete the last name: The data is released because no directory entry references it anymore.

For a practical reference on file-link behavior in Linux environments, see the GNU coreutils ln documentation and the stat manual.

When to Use a Hard Link in Linux

Use a hard link when you want two or more filenames to always reference the exact same content on the same filesystem. That is the cleanest use case, and it avoids duplicate storage without sacrificing access through different names.

Hard links work well in local file organization, simple retention workflows, and staging areas where the same file must remain available under multiple names. They are also useful when you want a safety net before deleting or replacing a file.

Practical Scenarios Where Hard Links Make Sense

• Release retention: Keep an unchanged artifact accessible under multiple labels.
• Local housekeeping: Provide a second name for a file before changing workflow scripts.
• Staging workflows: Reference the same content in a temporary path and a long-term path.
• Safe deletion planning: Remove one name while preserving access through another link.

One concrete pattern is log management. If you need a file to remain available to one process while another process references it under a different name, a hard link can keep both paths valid without duplication.

NIST guidance on configuration and data handling emphasizes controlled, consistent system behavior, and hard links can help preserve stable references when systems depend on local file identity. The concept is simple: if the same content must remain the same content, a hard link is often cleaner than a copy.

When to Use a Soft Link Instead

Use a symbolic link when you need flexibility, especially across directories or filesystems. A symlink is better when you want a shortcut, an alias, or a configurable pointer to a path that may change over time.

That is why symlinks are common for application configs, shared paths, and directory references. They can point across filesystem boundaries, while hard links cannot.

Why Symlinks Are Often the Better Operational Choice

• Directory targets: Symlinks can reference directories, which hard links usually cannot.
• Cross-filesystem paths: Symlinks can point anywhere a path can reach.
• Deployment convenience: Configuration files often use symlinks to swap versions quickly.
• Readable indirection: A symlink makes it obvious that one path is an alias to another path.

When the target is missing, the symlink breaks. That is not a bug; it is the expected behavior. Broken symlinks are useful to recognize during troubleshooting because they tell you the path moved or disappeared.

For filesystem and path behavior, official vendor documentation such as Microsoft Learn and the Linux documentation ecosystem both reinforce the same basic rule: path-based links are more flexible, but they are also more fragile.

How to Create a Hard Link in Linux

The basic command is simple: ln existing-file new-link-name. The existing file comes first, and the new hard link name comes second.

ln report.txt report-current.txt

That command creates another name for the same inode. If it succeeds, both names now reference the same file data on the same filesystem.

Common Mistakes When Creating the Link

1. Reversing the order of arguments.
2. Trying to link files across different mounted filesystems.
3. Assuming the result is a copy instead of a second name.
4. Forgetting to verify the inode number after creation.

Always check the result immediately. A successful command does not tell you whether you linked the correct file, only that the filesystem accepted the operation.

If you are working in Linux shell automation, this verification step matters. A wrong hard link can silently redirect updates to the wrong file, and that is the kind of mistake that shows up later in production or during cleanup.

How to Verify a Hard Link Correctly

The best way to verify a hard link is to compare inode numbers with ls -li and confirm the link count with stat. Matching inode numbers are the real proof that two names point to the same file.

ls -li report.txt report-current.txt

stat report.txt

If both names show the same inode and the link count is 2 or higher, the hard link exists. If the inode numbers differ, you are looking at two separate files, even if the filenames are similar or the contents match.

Quick Test After Creation

1. Edit one of the filenames.
2. Save the change.
3. Display the other filename.
4. Confirm the same change appears immediately.

That test is useful because it proves the link is shared at the data level, not merely copied at the name level. It is also a quick way to catch mistakes before a script or deployment moves forward.

The Linux kernel filesystem documentation is a solid reference when you need the underlying rules, especially if you are debugging behavior that does not match your expectations.

Why “Invalid Cross-Device Link” Happens

The invalid cross-device link error appears because hard links must stay within one filesystem. If the source and destination are on different mounts, Linux refuses the operation even if the command syntax is correct.

This is one of the most common hard link failures. People often think they mistyped the command, but the real issue is usually that the source lives on one filesystem and the destination lives on another.

How to Spot the Real Problem

• Check mount points with df -T or mount.
• Compare filesystem types for source and destination directories.
• Confirm the path is not crossing into a mounted volume such as /mnt or /media.
• Retry on the same filesystem if you need a hard link instead of a copy.

If you need to connect paths across filesystems, use a symbolic link instead. Hard links are tied to the filesystem boundary because the inode itself belongs to that filesystem. That limitation is fundamental, not optional.

For filesystem boundary behavior, the df manual and the Linux link(2) reference are the fastest ways to confirm the rule in a real shell session.

Can Hard Links Point to Directories in Linux?

Hard links to directories are generally restricted in Linux. The filesystem tries to avoid directory hard links because they can create loops, break tree consistency, and complicate traversal and cleanup.

Directories are not treated the same way as regular files. Linking a directory more than once can confuse recursive operations, create cycles, and make tools behave unpredictably. That is why symbolic links are the normal workaround when you need a directory reference.

Why the Restriction Exists

• Loop risk: Recursive tools could follow directory loops forever.
• Consistency risk: The filesystem hierarchy depends on predictable parent-child structure.
• Administrative safety: Deletion and traversal become far harder to reason about with multiple hard-linked directories.

If you need a reference to a directory, use a symlink. It is the accepted approach because it points to a path instead of trying to turn a directory into a multiply referenced object.

That rule also helps answer a frequent exam-style question: a source file and a symbolic link must be part of the same file system. False. A symbolic link can point across filesystems because it stores a path, not inode identity. A hard link, by contrast, must stay within the same filesystem.

Common Hard Link Mistakes and How to Avoid Them

The most common mistake is assuming a hard link is a copy. It is not. If you edit one name, every hard-linked name reflects the change because there is only one inode and one underlying set of data blocks.

Another frequent mistake is trying to create hard links across filesystems. That fails with Invalid cross-device link, and the fix is to either keep both names on the same filesystem or switch to a symlink.

Other Mistakes to Watch For

• Using the wrong link type in scripts and later discovering path breaks after a rename.
• Assuming filename identity instead of checking inode identity.
• Expecting a hard link to preserve history after the original inode is replaced with a new file.
• Deleting one name too early and misunderstanding why the data still exists.

For broader filesystem safety practices, the NIST Computer Security Resource Center is a useful source for disciplined configuration and change control thinking. Even though hard links are a storage feature, the operational mindset is the same: verify before you modify.

Hard Links in Real Linux Workflows

Hard links show up in real Linux work because they solve a very specific problem: how to give multiple names to the same content without duplicating the content. That makes them useful in command-line workflows, admin scripts, and retention tasks.

System administrators care about inode behavior because troubleshooting often depends on understanding whether a file was edited, replaced, renamed, or merely referenced through a second name. A filename alone does not always tell the full story.

Examples You See in Practice

• Temporary staging: A file is staged under one name and referenced again under another.
• Retention workflows: A file remains available even after one visible path is removed.
• Log and artifact handling: Multiple names can point to the same unchanged content until a controlled change occurs.

The idea also maps well to backup-like structures. Hard links let you preserve snapshots of names without storing duplicate data blocks for unchanged content, which is why file retention strategies often mention them. They are not a substitute for a true backup, but they are useful when you need multiple references to the same file state.

Hard links solve a naming problem, not a data-protection problem.

That distinction matters. For real protection and recoverability, use a backup strategy. For alternate names to the same local content, hard links are the right tool.

How to Think About Hard Links vs. “Resetting” or Replacing Files

A hard link relationship is about inode identity, not about resetting a file back to a previous state. If you replace a file by deleting it and creating a new one, you usually create a new inode, and the old hard link relationship ends with the old inode.

This is where scripts can get confusing. A process may keep referencing a file name and assume it still points to the same content, while another process has already replaced that file with a fresh copy under the same path.

Why Replacement Breaks Continuity

• Deleting and recreating a file usually generates a new inode.
• Existing hard links keep pointing to the old inode if it still has references.
• Path-based expectations can fail when the filename stays the same but the inode changes.

This is one of the biggest reasons Linux troubleshooting often starts with inode checks. A file can look identical by name while behaving differently underneath. When that happens, ls -li and stat reveal what actually changed.

The practical lesson is simple: if your workflow depends on the same file identity persisting, do not assume the filename guarantees that. Verify the inode. If the inode changes, the link relationship changed too.

Conclusion

A hard link in Linux is a second name for the same inode, while a symbolic link is a path reference to another file or directory. That difference explains the behavior people care about most: editing, deleting, moving, and verifying linked files.

Use hard links when you need multiple names for the same local content on the same filesystem. Use symbolic links when you need flexibility across directories, mount points, or changing paths. If you hit Invalid cross-device link, check your filesystem boundaries first instead of assuming the command is wrong.

The fastest way to avoid mistakes is to verify with inode-based commands, not filenames alone. In Linux, the name is just the label; the inode is the identity.

For deeper Linux file-system practice, ITU Online IT Training recommends reinforcing this topic with hands-on shell verification, because hard links make the most sense when you can see the inode numbers and link counts for yourself.

Linux and GNU coreutils are referenced for educational purposes. Linux® is a registered trademark of Linus Torvalds. GNU® is a registered trademark of the Free Software Foundation.