Eric Campbell 6 min read Linux

Linux Symbolic Links vs Hard Links

Linux links solve a fundamental problem: how do you reference the same file from multiple locations without duplicating data? Whether you're managing configuration files, creating backup systems, or...

Key Insights

  • Hard links create multiple directory entries pointing to the same inode, meaning the file persists until all links are deleted, but they cannot cross filesystem boundaries or link directories.
  • Symbolic links are special files containing path references that work across filesystems and can link directories, but they break if the target is moved or deleted.
  • Use hard links for backup systems and deduplication on the same filesystem; use symlinks for configuration management, version switching, and any cross-filesystem references.

Linux links solve a fundamental problem: how do you reference the same file from multiple locations without duplicating data? Whether you’re managing configuration files, creating backup systems, or organizing complex directory structures, links provide efficient file references that save disk space and simplify maintenance.

The filesystem treats links differently from copies. A copy creates an entirely separate file consuming additional disk space. Links, by contrast, create references to existing data. Understanding when to use links versus copies—and which type of link to choose—is essential for effective Linux system administration.

Hard links operate at the inode level, which is the fundamental data structure that stores file metadata in Unix-like filesystems. When you create a file, the filesystem assigns it an inode number. The directory entry (filename) simply points to this inode. A hard link creates an additional directory entry pointing to the same inode.

This means both filenames reference identical data. They’re not copies—they’re truly the same file with multiple names. The filesystem maintains a reference count on each inode, and the actual data isn’t deleted until all hard links are removed.

Creating a hard link is straightforward:

# Create an original file
echo "Important data" > original.txt

# Create a hard link
ln original.txt hardlink.txt

# Verify they share the same inode
ls -li original.txt hardlink.txt

The output shows identical inode numbers:

2621483 -rw-r--r-- 2 user user 15 Jan 15 10:30 hardlink.txt
2621483 -rw-r--r-- 2 user user 15 Jan 15 10:30 original.txt

Notice the “2” after the permissions—that’s the link count. Both files share inode 2621483. Modifying either file changes both because they’re the same underlying data:

echo "Modified content" >> hardlink.txt
cat original.txt
# Output: Important data
#         Modified content

Hard links have critical limitations. They cannot cross filesystem boundaries because inode numbers are only unique within a single filesystem. You also cannot create hard links to directories (except for the special . and .. entries) because allowing this would enable circular references that could break filesystem traversal algorithms.

Symbolic links take a different approach. A symlink is a special file type that contains a text string representing the path to another file or directory. Think of it as a shortcut or pointer. When you access a symlink, the system reads the path stored inside and redirects you to the target.

Creating a symlink requires the -s flag:

# Create a symbolic link
ln -s /home/user/documents/report.txt report_link.txt

# Display the symlink
ls -l report_link.txt

The output clearly shows the symlink relationship:

lrwxrwxrwx 1 user user 31 Jan 15 10:35 report_link.txt -> /home/user/documents/report.txt

The l at the start indicates a symbolic link, and the arrow shows where it points. Symlinks can contain either absolute or relative paths, which affects portability:

# Absolute symlink - works from anywhere
ln -s /var/log/nginx/access.log nginx_log.txt

# Relative symlink - works when directory structure is preserved
ln -s ../config/settings.conf settings_link.conf

Relative symlinks are particularly useful when you need to move entire directory trees while maintaining internal references. Absolute symlinks are clearer but less portable.

Unlike hard links, symlinks can cross filesystem boundaries and link to directories:

# Link to a directory on a different filesystem
ln -s /mnt/external_drive/backups /home/user/backups

# Link to a directory
ln -s /usr/share/nginx/html /var/www/site

Key Differences Comparison

Understanding the behavioral differences helps you choose the right link type:

Inode behavior: Hard links share the same inode; symlinks have their own inode containing the path string.

Filesystem boundaries: Hard links must stay within one filesystem; symlinks work across any mounted filesystem.

Directory linking: Hard links cannot link directories; symlinks can link both files and directories.

Broken links: Hard links cannot break as long as one link exists; symlinks break if the target is moved or deleted.

Disk space: Hard links consume no additional space for data (only a directory entry); symlinks use minimal space for the path string.

Deletion behavior: Deleting a hard link decrements the reference count; deleting a symlink removes only the pointer.

Let’s demonstrate deletion behavior:

# Hard link example
echo "data" > original.txt
ln original.txt hardlink.txt
rm original.txt
cat hardlink.txt
# Output: data (file still exists)

# Symlink example
echo "data" > target.txt
ln -s target.txt symlink.txt
rm target.txt
cat symlink.txt
# Output: cat: symlink.txt: No such file or directory (broken link)

The stat command provides detailed link information:

stat hardlink.txt
# Shows: Links: 1 (decremented after removing original.txt)

stat symlink.txt
# Shows: symbolic link to 'target.txt'

Practical Use Cases

Symlinks excel in configuration management. Many Linux services use symlinks to enable or disable configurations:

# Nginx sites-enabled pattern
cd /etc/nginx/sites-enabled
ln -s ../sites-available/mysite.conf mysite.conf

# Disable by removing symlink (config preserved in sites-available)
rm mysite.conf

This pattern allows you to maintain all configurations in one location while selectively activating them. It’s cleaner than copying files and easier to manage than commenting out configurations.

Version management is another strong use case for symlinks:

# Manage multiple application versions
ln -s /opt/app/versions/app-2.1.0 /opt/app/current

# Upgrade by changing the symlink
rm /opt/app/current
ln -s /opt/app/versions/app-2.2.0 /opt/app/current

This enables instant rollbacks and zero-downtime deployments.

Hard links shine in backup and deduplication systems. Tools like rsync and Time Machine-style backups use hard links to save space:

# Create space-efficient incremental backups
rsync -a --link-dest=../backup-2024-01-14 /source/ /backups/backup-2024-01-15/

This creates a new backup where unchanged files are hard-linked to the previous backup, consuming no additional space while appearing as complete snapshots.

Deduplication scenarios also benefit from hard links:

# Find and deduplicate identical files
fdupes -r /path/to/files

# Replace duplicates with hard links
fdupes -r -L /path/to/files

Common Pitfalls and Best Practices

Circular symlinks create infinite loops that can crash scripts:

# Don't do this
ln -s link1 link2
ln -s link2 link1

Most modern tools detect circular references, but they still cause problems. Always validate your link structure.

Broken symlinks accumulate over time as files are moved or deleted. Find them with:

# Find all broken symlinks under /path
find -L /path -type l -ls

# Find and delete broken symlinks
find -L /path -type l -delete

The -L flag tells find to follow symlinks, so -type l matches only broken ones.

Use readlink to resolve symlink paths:

# Show where a symlink points
readlink /etc/nginx/sites-enabled/default

# Follow the entire chain to the final target
readlink -f /etc/nginx/sites-enabled/default

This is invaluable for debugging complex link chains.

Permission considerations: Operations on symlinks generally affect the target, not the link itself. However, ownership of the symlink can matter for security:

# Symlink ownership doesn't affect access (target permissions apply)
# But symlink ownership matters in sticky bit directories like /tmp

Portability concerns: Not all systems handle symlinks identically. Windows requires special privileges for symlink creation, and some backup tools don’t preserve them correctly. Test your workflows across target platforms.

Making the Right Choice

Choose hard links when you need multiple references to the same file on a single filesystem, particularly for backup systems, deduplication, or when you want the file to persist regardless of which name is deleted. They’re transparent—users cannot tell which is the “original.”

Choose symbolic links when you need flexibility: cross-filesystem references, directory links, version management, or clear indication of which file is the reference versus the target. They’re explicit and versatile but require the target to remain accessible.

For most configuration and organizational tasks, symlinks are the pragmatic choice. For space-efficient backups and deduplication on the same filesystem, hard links are superior. Understanding both gives you the full toolkit for effective Linux file management.

Liked this? There's more.

Every week: one practical technique, explained simply, with code you can use immediately.