A hard link is a directory entry that associates a file name with an existing inode, so that one file on a Linux filesystem can be reached under two or more names. All hard links to a file are equal: none of them is the original, and each one gives direct access to the same data, the same permissions and the same timestamps.
Hard links exist because Unix-style filesystems separate a file’s name, stored in a directory, from the file itself, described by an inode. The inode keeps a link count, and the file’s data is freed only when that count drops to zero and no process still holds the file open.
How a hard link works at the inode level
A directory on a Linux filesystem such as ext4, XFS or Btrfs is essentially a table that maps names to inode numbers. Creating a hard link with ln source target, or with the link() system call, adds a new row to such a table that points to an inode already in use, and it increments the inode’s link count by one.
Removing a name with rm calls unlink(), which deletes only the directory entry and decrements the link count. The data blocks stay allocated as long as at least one link remains or a process keeps the file open. This explains why rm never truly deletes a file that has another hard link, and why disk space from a deleted log file may not return until the writing process closes it.
| Operation | Effect on inode | Effect on other names |
|---|---|---|
| ln a b | Link count increases by one | Name a and name b share data |
| rm a | Link count decreases by one | Name b keeps working |
| Edit through a | Data changes in place | Change visible through b |
| chmod a | Permissions change in inode | Same permissions through b |
| mv a elsewhere | No change if same filesystem | Name b unaffected |
The link count is visible in the second column of ls -l and in the output of stat. The command ls -i prints inode numbers, and find with the -samefile or -inum option lists every name that refers to one inode.
Restrictions on hard links
Hard links are constrained by the inode model itself. Because an inode number is meaningful only within one filesystem, a hard link cannot cross filesystem or mount point boundaries; attempting it fails with the error EXDEV, invalid cross-device link.
- No hard links to directories for ordinary users, because they could create loops that break tree traversal and fsck; the only directory links are the automatic . and .. entries.
- Same filesystem only, so a link from a home partition to a separate data partition is impossible.
- Maximum link count depends on the filesystem; ext4 allows about 65,000 links per file, while XFS and Btrfs allow far more.
- With the protected_hardlinks kernel setting enabled, which is the default on most distributions, users cannot create hard links to files they do not own or cannot read and write.
The protected_hardlinks protection exists because hard links were once abused in privilege escalation attacks, where an attacker linked a sensitive file into a directory that a privileged program later modified.
Hard link compared with symbolic link and other mechanisms
The closest neighbor of the hard link is the symbolic link, which stores a path rather than referring to an inode. The two behave very differently when files are moved or deleted.
| Property | Hard link | Symbolic link |
|---|---|---|
| Points to | An inode | A path string |
| Has its own inode | No | Yes |
| Crosses filesystems | No | Yes |
| Links to directories | No | Yes |
| Survives deleting the other name | Yes | No, becomes dangling |
| Shows target in ls -l | No | Yes, as an arrow |
Hard links should also be distinguished from copies and from reflinks. A copy duplicates the data, so later edits to one copy do not affect the other. A reflink, available on Btrfs and XFS with cp –reflink, shares data blocks copy-on-write: the files start identical and diverge independently when edited. A bind mount makes a whole directory tree visible at a second location and, unlike a hard link, works for directories and across filesystems.
Practical uses of hard links
Hard links are valuable whenever identical files should share storage while remaining independently named. The following table summarizes established use cases.
| Use case | How hard links help | Typical tool |
|---|---|---|
| Incremental backups | Unchanged files link to the previous snapshot | rsync with –link-dest |
| Package caches | One stored file serves many environments | Language package managers |
| Deduplication | Identical files become one inode | hardlink or rdfind |
| Atomic replacement | A new name is linked before the old one is removed | Mail and spool systems |
Snapshot-style backups with rsync –link-dest are the classic example: each daily directory looks like a complete copy, but only files that changed consume new space. Deleting an old snapshot is safe, because files still needed by newer snapshots keep their remaining links.
Pitfalls and common mistakes
The defining property of hard links, shared data, is also their main risk. Editing a file through one name changes it for every name, which surprises users who believe they made a backup copy.
Behavior also depends on how programs save files. An editor that writes in place modifies the shared inode, while an editor that writes a new file and renames it over the old name breaks the link, leaving the other name with the old content. Tools such as tar and rsync preserve hard links only with specific options, such as rsync -H, otherwise a restore may multiply disk usage.
In simple terms
A hard link is a second name for the same file. Imagine one house that has two different street addresses. Whichever address a visitor uses, they arrive at the same house and see the same rooms.
If one address is removed from the map, the house still stands and is reachable through the other address. The house disappears only when its last address is removed. That is exactly how a file with hard links behaves.
A practical example
A system administrator keeps 30 days of backups for a file server holding about 400 gigabytes of documents. Full daily copies would need roughly 12 terabytes. Instead, each night she runs rsync with –link-dest pointing to the previous day’s backup, so unchanged files become hard links to the existing inodes and only the few gigabytes of changed files are written.
The 30 snapshots together occupy only a little more than the original data plus the daily changes. When a user asks for a contract as it looked two weeks ago, the administrator simply opens that day’s directory. Expired snapshots are removed with rm -r, and space is freed only for files that no newer snapshot still links to.