Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Part of my migration strategy of moving to Amazon EC2 for our servers involves making use of symlinks to keep installs and files in their 'standard' locations on the servers but the actual storage of logs files, data, etc. on EBS storage, for persistence. After the server starts up, I run scripts that create symlinks to the config files and data stored on the EBS to 'convert' the server to the setup I need.

Since I'm not a true Linux sysadmin (small company developer), I'm nervous about any sort of gotchas I might be unaware of by using symlinks. Things like breaking software packages or other difficulties where the applications might not like utilizing symlinks are what I'm concerned about.

Are there any common gotchas using symlinks or are they pretty foolproof?

share|improve this question
you can make the title more explanatory. – hayalci Jul 14 '09 at 19:32
up vote 4 down vote accepted

If you are only soft symlinking directories - rather than files - then they should for the most part behave entirely transparently.

The only issue that you may stumble across is some applications which resolve and then continue to refer to the real path of the link. Which can cause issues if you choose to change the source of the link at a later stage.

share|improve this answer
Mostly it's soft links to directories, but I was thinking of linking to some config files directly. right now I copy any files that would need to be linked directly. If we did change the actual location (which is partly the reason I'm linking) it would likely be part of a restart procedure as well, so I'm thinking cached paths are probably not going to be an issue. I'm trying stay away from the try it and see what fails mindset as much as possible. – ahanson Jul 14 '09 at 17:05
Configs shouldn't be an issue either. So long as it isn't anything that's modified as part of an automated process and expects to behave like a "normal file". Specifically logs, as you might expect. Actually I have more problems with developers using the realpaths of links than I do applications mistakenly picking them up. – Dan Carley Jul 14 '09 at 18:05
"some" programs fail when their configuration file is a symlink, I cannot remember "which", but be careful. – hayalci Jul 14 '09 at 19:33

Yeah, stay away from "hard" links, as you can easily create chaos with them. Hard symlinks are just a "re-appearance" of the same file in a different part of the filesystem, i.e. it literally creates a 2nd entry in the directory structure of the filesystem with a direct link to the file data. They have their uses but generally speaking, you're better off with "Soft" symlinks, which are akin to Windows shortcuts (although much different in implementation) in that they are just a pointer back to the original file. These are your best bet.

Deleting a soft symlink deletes the link. Deleting a hard symlink can delete the file if you're not careful.

share|improve this answer
the terminology is "hard links" and "symbolic links" (symlinks) – hayalci Jul 14 '09 at 19:30
and, you cannot create hardlinks to a file on another filesytem anyway. – hayalci Jul 14 '09 at 19:31
@hayalci, don't care about 'other filesystems'; I care about being exhausted from a 18-hour marathon don't-eat don't-sleep session and making the mistake of deleting what I thought was a symlink...only to find out it was the last hardlink of a file, and the file is gone... It's mostly a "safety" issue for me. – Avery Payne Dec 13 '11 at 14:20

Hard links, as someone pointed out, make second entries in the file system. You can only use that on the same partition and for files, not directories. If you delete all the hard links to a file then the file does get deleted.

Soft links, ie, symbolic links, just make an entry in the directory which lets you easily see, ONE DIRECTION, where the real file is stored.

What you don't get is any knowledge at the other end that multiple symlinks point to a file. If you move or delete the file all the symlinks break.

Used in moderation, symlinks are fine. You should think hard if you find that a symlink points to a symlink which points to yet another symlink before reaching the real file. You are probably doing something wrong then...

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.