Creating a Symbolic Link with ln -s What Comes First?

Published on July 13, 2020
By Pete Freitag

One thing I've had to google more times than I'd like to admit is the path argument order for the ln command. What comes first in the ln -s command on linux or Mac? So I thought I'd write a little blog entry for future me to find.

Here's an example:

ln -s /real/path /linked/path

To answer my own question, you put the existing path first (source file), then the link path (target file) you want to create second.

A good way to try to remember this is that it is the same order as the cp command if you were to copy a file from one path to a new path, you always put the existing file path first. The same goes for ln, but unless you create symbolic links every day you'll probably forget this by the next time you need to create one.

It doesn't matter if you are running Mac, Linux, Ubuntu, RedHat the syntax will always be ln -s source target

ln: No such file or directory Error

Recently when attempting to create a symbolic link from one folder to a new linked folder, I received this error:

ln: /linked/path/: No such file or directory

That seamed like a rather odd error since that linked path was the link I was attempting to create, of course it doesn't exist. This led me to immediately think I mixed up the order of the target and source paths, but I did have them in the correct order. The cause of that error for me was simply that I put a trailing slash on the linked path. Removing that trailing slash fixed the problem for me.

linux mac bash ln ubuntu redhat

Creating a Symbolic Link with ln -s What Comes First? was first published on July 13, 2020.

If you like reading about linux, mac, bash, ln, ubuntu, or redhat then you might also like:

Weekly Security Advisories Email

Advisory Week is a new weekly email containing security advisories published by major software vendors (Adobe, Apple, Microsoft, etc).

Comments

I have super explicit comments in code that uses mklink because left to memory, I get them backwards like 90% of the time. Totally with you on this!

by Mark Gregory on 07/14/2020 at 12:49:27 PM UTC

Hey Pete,

There's some subtlety with ln.

If you use ln for hardlinks - it will ensure the source exists.

ln file1 file2

If file1 does not exist, it will not succeed. That means file1 is always a full path, or relative to your current location.

When doing a symbolic link, the source doesn't have to exist at all.

ln -s doesnotexist /tmp/somefile

Will create a broken link in /tmp/somefile, pointed at "doesnotexist". Which, when accessed, will be accessed from /tmp

This can be really important when you're creating symlinks with relative references, ../ for instance, across symlinks that may already exist. You always want to make sure the source *will* exist based on where you're placing the link. If you use an absolute path in the source, the symlink will have that absolute reference. This can cause problems in things like containers, where your link may be accessed from inside or outside a container, and the reference may need to be relative to work in both cases.

The other, main thing that makes it easy to remember what the order is is that you can do:

ln -s /bin/true /root/

And you'll end up with /root/true linked to /bin/true.

mkdir /root/bin
ln -s /bin/* /root/bin/

You can have MULTIPLE sources, in which case it only makes sense that the second one (which in that case has to be a directory) is your destination.

by Joe Gooch on 07/16/2020 at 5:29:24 PM UTC