A symbolic link is a pointer file that references another file or directory by path. Create one with ln -s target linkname. Unlike copying a file, a symlink takes almost no disk space and always reflects the current state of whatever it points to - edit the target, and every symlink pointing at it sees the change immediately.
Symlinks are common in web hosting for things like pointing a domain's document root at a shared folder, keeping a "current" release pointing at the latest deploy, or making a file accessible from two locations without duplicating it. They work the same way whether you're on shared hosting or a VPS, though where you're allowed to point them differs.
Creating a symlink
The basic syntax is:
ln -s /path/to/target /path/to/linkname
The -s flag is what makes it symbolic (soft). Without it, ln creates a hard link instead, which is a different thing entirely (more on that below). Order matters: the target (the real file or folder) comes first, the link name (the new pointer) comes second. A common mistake is reversing the order, which creates a link with the wrong name pointing the wrong direction.
To link a directory:
ln -s /home/user/public_html/shared-assets /home/user/public_html/site2/assets
Now anything inside site2/assets is really being read from shared-assets.
To link a single file, for example pointing a config file at a shared version:
ln -s /home/user/configs/wp-config-base.php /home/user/public_html/wp-config.php
Relative vs absolute paths
You can use either an absolute path (starting with /) or a relative path (based on your current directory) as the target. Absolute paths are safer when the link and target might move independently, or when you're not sure what directory a script will run from. Relative paths are useful when you want a set of files to stay linked correctly even if you move the whole folder structure somewhere else, since the relationship between the link and target doesn't change.
Check where a symlink actually points with:
ls -la
Symlinked entries show up with an l at the start of the permissions string and an arrow to the target, like assets -> /home/user/public_html/shared-assets.
Removing a symlink
Use rm, not rm -r:
rm /path/to/linkname
This is important: rm on a symlink deletes only the pointer, not the target. But if you accidentally add a trailing slash and treat it like a directory, or use a recursive file manager action on what you think is a folder, you can end up affecting the target's contents instead. When in doubt, run ls -la first to confirm you're looking at a link and not the real directory.
Broken symlinks
If the target is moved, renamed, or deleted, the symlink still exists but points at nothing. Accessing it returns a "No such file or directory" error even though ls shows the link itself. Find broken symlinks in a directory tree with:
find /home/user/public_html -xtype l
Fix a broken link by removing it and recreating it with the correct target, or by updating the target path if it moved rather than disappeared. This is a common cause of a site suddenly showing missing images or includes after a folder gets renamed during cleanup - check for broken symlinks before assuming files were lost.
Symbolic links vs hard links
A hard link (ln without -s) makes a second directory entry pointing at the same underlying data on disk. There's no "original" and no "copy" - both names are equally real, and the data isn't freed until every hard link to it is removed. Hard links can't cross filesystems and can't point at directories. Symbolic links can do both of those things, which is why they're the more common choice for general use. Stick with -s unless you specifically need the hard-link behavior.
Where root access matters
On shared hosting, you're limited to your own account's file space, and system-level paths outside your home directory aren't writable. On a VPS with root access, you can create symlinks anywhere on the filesystem, including into system directories like /etc or /usr/local. That extra reach is also extra responsibility: a symlink placed in the wrong system path can break services that expect a real file there.
When to contact support
If a symlink you didn't create is causing unexpected behavior, or you're not sure whether removing one will affect other accounts or shared infrastructure on your plan, open a ticket from the portal's Support section rather than guessing.