How to Create a Symlink in Linux: A Complete Guide
Symbolic links are one of Linux's most useful filesystem features — and once you understand how they work, you'll find yourself reaching for them regularly. Whether you're managing config files, organizing project directories, or pointing software to the right location, knowing how to create and manage symlinks is a core Linux skill.
What Is a Symlink?
A symbolic link (symlink) is a special file that acts as a pointer to another file or directory. Think of it like a shortcut on Windows or an alias on macOS — except symlinks are deeply integrated into how Linux handles files at the filesystem level.
When you access a symlink, the operating system automatically follows the pointer and gives you the contents of the target. To most programs, the symlink is invisible — they just see the file or directory it points to.
This is different from a hard link, which creates a second directory entry pointing to the same underlying data blocks. Symlinks can span different filesystems and can point to directories; hard links generally cannot.
The Basic Command: ln -s
Creating a symlink in Linux uses the ln command with the -s flag (for symbolic):
ln -s [target] [link_name] - target — the file or directory you want to point to
- link_name — the name and location of the symlink itself
Example: Linking a File
ln -s /home/user/documents/config.txt /home/user/Desktop/config-shortcut.txt This creates a symlink called config-shortcut.txt on the Desktop that points to the original file in Documents. Edit either one, and the changes appear in both — because they're the same underlying file.
Example: Linking a Directory
ln -s /var/www/html/myproject /home/user/myproject This places a symlink in your home directory pointing to a web project folder. You can navigate into it, list its contents, and modify files exactly as if you were in the real directory.
Verifying a Symlink
Use ls -l to confirm the link was created and check where it points:
ls -l /home/user/myproject The output will show an arrow indicating the target:
lrwxrwxrwx 1 user user 20 Jun 10 10:00 myproject -> /var/www/html/myproject The l at the start of the permissions string identifies it as a symbolic link. You can also use readlink to print just the target path:
readlink /home/user/myproject Overwriting an Existing Symlink
If a symlink already exists at your chosen path, ln -s will throw an error. To replace it, add the -f (force) flag:
ln -sf /new/target/path /home/user/myproject Be careful with -f — it will silently overwrite the existing link without confirmation.
Absolute vs. Relative Symlink Paths 🔗
One of the most common sources of broken symlinks is the choice between absolute and relative paths.
| Path Type | Example | Behavior |
|---|---|---|
| Absolute | /home/user/docs/file.txt | Works from anywhere; breaks if target moves |
| Relative | ../docs/file.txt | Depends on symlink's own location; portable if structure stays intact |
Absolute paths are simpler and less error-prone for most use cases. If you move the symlink itself, it still points to the right place. But if the target file moves, the link breaks.
Relative paths are useful when you're building portable directory structures — for example, in a dotfiles repository where you want everything relative to a home directory that might be named differently on each machine.
What Happens When a Symlink Breaks?
A broken symlink (also called a dangling symlink) occurs when the target file or directory no longer exists. The symlink file itself remains, but accessing it returns an error.
To find broken symlinks in a directory:
find /path/to/directory -xtype l This lists all symlinks whose targets don't exist. You can then delete or update them as needed.
Removing a Symlink
Delete a symlink using rm or unlink — not rmdir, which is for actual empty directories:
rm /home/user/myproject # or unlink /home/user/myproject Critically: removing the symlink does not delete the target. The original file or directory remains untouched.
Where Skill Level and Setup Change the Equation 🖥️
The mechanics of ln -s are consistent across Linux distributions — the command works the same on Ubuntu, Fedora, Arch, or Debian. What varies is where and why you'd use it:
- System administrators frequently use symlinks for managing configuration files across multiple environments, linking versioned binaries (e.g.,
python3.11aliased topython3), or keeping logs in standard locations while storing data on different disks. - Developers use them to link shared libraries, manage dotfiles across machines, or create environment-specific paths without duplicating code.
- Desktop users might use symlinks to point application folders at different drives without the application knowing.
Each of these scenarios involves slightly different decisions: whether to use absolute or relative paths, whether the symlink needs to survive across system changes, and whether the applications accessing the link are symlink-aware.
The command itself is simple. What requires judgment is understanding how your specific filesystem layout, your software's behavior, and your intended workflow interact — because a symlink that works perfectly in one setup can become a maintenance headache in another.