How to find and remove broken symlinks in Linux

A terminal window on a Linux laptop.

Symbolic links in Linux are a great feature, but they can be broken and left pointing to nothing. Here’s how to locate broken symbolic links, review them, and remove them from your system if necessary.

Symbolic links 101

Symbolic links, also called “soft links” and “symbolic links,” are a form of shortcuts that can point to files and directories. A symbolic link looks like a normal file or directory in a file manager window. It also appears as an entry in a file list in a terminal window. The file or directory that the symbolic link points to can be anywhere in the file system tree.

For example, let’s say you have a symbolic link in your home directory called “dave-link” that points to a file called “text-file.txt” located somewhere else in the filesystem tree. The commands that you use in the symbolic link are automatically applied to the file that you point to. If you try to use cat or less In the symbolic link, you will see the content of the file “text-file.txt”.

A standard Linux installation contains many symbolic links. Even if you don’t create them yourself, the operating system uses them. Application installation routines often use symbolic links to point to executable files. When the software is updated, the binary file is replaced by the new version and all symbolic links continue to work as before, as long as the name of the new file is the same as the old one.

We can easily see some symbolic links using ls in the root directory. Some of the tickets are shown in a different color; on our Ubuntu 20.10 test machine, they are shown in light blue.

We write the following:

ls /

We can take a deeper look by using the -l (long list) option. We write the following command to see all the “lib” entries and the only “bin” entry:

ls -l /lib* /bin

At the beginning of each line there is an “l”, which indicates that the element is a symbolic link. The text after the “->” shows what the symbolic link points to. In our example, the destinations are all directories.

Permissions are listed as read, write, and execute for owner, group, and others. These are default bogus entries. They do not reflect the actual permissions on the objects pointed to by the symbolic links. It is the permissions on the destination file or directory that take precedence and are respected by the file system.

Broken symbolic links

A symbolic link is broken (or left hanging) when the file it points to is deleted or moved to another location. If an app’s uninstall routine doesn’t work properly or is interrupted before it completes, you might be left with broken symbolic links.

If someone manually deletes a file without knowing that the symbolic links point to it, those symbolic links will stop working. They will be like road signs pointing to a city that has been razed.

We can easily see this behavior by using a symbolic link called “hello” in the current directory. We write the following, using ls to view:

ls -l

It points to a program called “htg” in a directory called “bin”. If we “run” the symbolic link, it runs the program for us:

./hello

Now we can check if this is what is happening by running the program directly:

../bin/htg

Unsurprisingly, we get the same response. Let’s delete the program file:

rm ../bin/htg

Now when we look at the symbolic link, we see that it is in red because Linux knows that it is broken. It also tells us what it used to point to, so we can replace the file, recompile the program, or do whatever it takes to repair the symlink.

Note that if we try to execute the symbolic link, the error we get refers to the name of the symbolic link, rather than the name of the program that the symbolic link points to.

We write the following:

./hello

Find broken symbolic links

Most modern versions of find have the xtype option (extended type), which simplifies the search for broken symbolic links. We will use the l flag with xtype, to instruct you to search for links. Using find Y xtype as follows, without any of the others type flags, forces xtype to return broken links:

find . -xtype l

Running the command in our test home directory, quite a few broken symbolic links are found. Note that the search is recursive by default, so it searches all subdirectories automatically.

The “hello” symbolic link that we broke on purpose appears in the list, as we expected. One of the other symbolic links is related to the Firefox browser, and the rest are associated with snapshots.

If we funnel the output through wc with the -l (lines), we can count the lines, which is the same as counting the broken symbolic links.

We write the following:

find . -xtype l | wc -l

We are informed that we have 24 broken symlinks that point to nothing.

Find, review, and then remove

Before you rush and delete all the broken symlinks, check out the results of the find I send. See if there is a valid reason for any of the broken symlinks.

Sometimes the symbolic link can be the problem, rather than the destination file. If the symlink was created incorrectly, it may not point to anything, but the actual target is present. In that case, the solution would be to recreate the symbolic link.

It is also possible that a seemingly broken symbolic link is being used as something else, such as a file lock indicator or another go / no go indicator. Firefox does this; that’s the first symlink on our list. However, Firefox is not used on our test machine, so it is safe for us to remove it.

It’s also possible that the target is only present periodically, and this is the expected (and desired) behavior of that particular software. Perhaps the destination file is copied from another machine or from the cloud, performs its function, and then deleted again, only to be replaced by a different program in the next cycle.

The broken symbolic link can also be a symptom of a failed software installation. In that case, instead of removing the symbolic link, you need to fix it manually or repeat the installation.

When you have fixed the broken links you need to keep, repeat the command to perform the search. Hard symlinks should be absent from search results.

For the sake of security, it’s best to limit symlink removals to your own directories. Be very careful when running these commands as root or in system directories.

Remove broken symbolic links

The -exec The (run) option executes commands on the find Search results. We will use rm to remove every broken symbolic link. The {} The string is replaced with the name of each broken symlink as each is discovered by find.

We have to use a semicolon (;) to finish the list of commands we want -exec run. We will use a backslash () to “escape” the semicolon, so it is treated as part of the find command, instead of something Bash must act.

We write the following:

find . -xtype l -exec rm {} ;

We go back to the command prompt without any indication that something has happened. To verify that the broken links have been eliminated, we repeat the command to search for them, as follows:

find . -xtype l

There are no matching results, which means the broken symbolic links have been removed.

Remember to check first

Again, always take the time to review a list of symbolic links before running the command to remove them. You can avoid removing any that you are unsure of by running the command to remove them in the appropriate directories.

For example, above, we could have run the command in the “.snap” directory and then manually removed the lonely “hello” symlink. This would have left the Firefox blocking symlink intact.

Leave a Reply