I am reading this intro to the command line by Mark Bates.

In the first chapter, he mentions that hard links cannot span file systems.

An important thing to note about hard links is that they only work on the current file system. You can not create a hard link to a file on a different file system. To do that you need to use symbolic links, Section 1.4.3.

I only know of one filesystem. The one starting from root (/). This statement that hard links cannot span over file systems doesn't make sense to me.

The Wikipedia article on Unix file systems is not helpful either.


5 Answers 5


Hopefully I can answer this in a way that makes sense for you. A file system in Linux, is generally made up of a partition that is formatted in one of various ways (gotta love choice!) that you store your files on. Be that your system files, or your personal files... they are all stored on a file system. This part you seem to understand.

But what if you partition your hard drive to have more than one partition (think Apple Pie cut up into pieces), or add an additional hard drive (perhaps a USB stick?). For the sake of argument, they all have file systems on them as well.

When you look at the files on your computer, you're seeing a visual representation of data on your partition's file system. Each file name corresponds to what is called an inode, which is where your data, behind the scenes, really lives. A hard link lets you have multiple "file names" (for lack of a better description) that point to the same inode. This only works if those hard links are on the same file system. A symbolic link instead points to the "file name", which then is linked to the inode holding your data. Forgive my crude artwork but hopefully this explains better.

image.jpg             image2.jpg
          \           /
           [your data]

here, image.jpg, and image2.jpg both point directly to your data. They are both hardlinks. However...

image.jpg    <-----------  image2.jpg
             [your data]

In this (crude) example, image2.jpg doesn't point to your data, it points to the image.jpg... which is a link to your data.

Symbolic links can work across file system boundaries (assuming that file system is attached and mounted, like your usb stick). However a hard link cannot. It knows nothing about what is on your other file system, or where your data there is stored.

Hopefully this helps make better sense.

  • 1
    Thanks. I didn't realize different file-partitions are called "file systems."
    – b0yfriend
    Jun 18, 2016 at 6:37
  • 1
    one of the things you can do with a partition is put a filesystem on it, there are other places you can put filesystems and other things you can do with partitions, but the most-common option is that one.
    – Jasen
    Jun 18, 2016 at 9:53
  • 12
    There's one file hierarchy that starts at "/". It will have one or more file systems mounted
    – mpez0
    Jun 18, 2016 at 21:29
  • @mpez0: Not even, with e.g. chroot(2) or real containerization you can have multiple hierarchies, which may have nothing whatsoever to do with each other.
    – Kevin
    Jun 19, 2016 at 5:40
  • @Kevin,chroot isolates a portion of the hierarchy for a process and its descendants, but the parent still has one complete hierarch. Containerization may do it, depending on how close to a VM it is. But how much detail can one pack into a comment? Thanks,
    – mpez0
    Jun 20, 2016 at 12:12

The File system is composed by a directory structure composed for directory entries to organize files. Each directory entry associates a file-name with an inode.

Soft links (symbolic) are directory entries that does not contain data, it just points to another entry (a file or directory in the same file system or other file system). And when you delete the pointed file, the symbolic link becomes unusable.

Hard links are directory entry that contains the file name and inode number. When you remove the last hard link, you can no longer access the file.

Difference between soft-link and hard-link


As the inode is a data structure used to represent a file-system object, it's internal to the File system, and you can't point to an inode of another file system.

Thus, hard-links are only valid within the same File system, but soft-links (Symbolic link) can span file systems as they simply point to another directory entry (The interface of the file-system, and not an internal object).

  • What will happen if another file system (let's say USB) will have a file with the same NAME, to which our symbolic link is connected on our file system? Apr 29, 2018 at 10:11
  • @JosefKlimuk, a soft link would point to a path, let's say /mnt/myfile. If you mount another file system into /mnt/. The soft link would be resolved to an entry of the mounted file system under /mnt/. Thus, if you mounted the file system from your USB device on /mnt, the soft link would resolve to an entry on that file system. Apr 29, 2018 at 18:57

Hard links have the effect of keeping their target alive. As long as any hard link is reachable, the system will ensure that its target cannot get released. It is therefore necessary that all media that could contain hard links to a particular inode be mounted any time the system would be trying to determine whether any references exist to it.

Given that inode lifetime is usually determined by maintaining reference counts rather than scanning for references, it might be possible to arrange things to that two or more file systems that held links to each other could be used independently provided there was no need to use links which bridged between the systems, and provided there was no need to use fsck on either one. If inode counts on one of the systems got disturbed, however, the only way to make that system useful again would be to use a form of fsck operation which could scan both file systems for references. Because of that constraint, while it might be possible to allow two inter-linked file systems to be usable independently, the benefits of doing so would probably be too limited to make it worthwhile.

  • Good point, but a bit too tangential to be good answer.
    – Joe
    Jun 25, 2016 at 3:21
  • @Joe: Allowing hard links to cross file systems would impose a number of technical difficulties, but most of them could be overcome, thus raising the question of whether there's any compelling reason why they shouldn't be. The keep-alive issue may seem obscure, but unlike the other issues it can only me resolved by imposing severe semantic restrictions on the usage of such links, which would severely limit their value.
    – supercat
    Jun 25, 2016 at 13:15
  • 1
    Good point. A filesystem can be mounted on another device and modified, so the inode and links can get "out of sync". Every filesystem could have a GUID and the link could incorporate that GUID to track the inode across filesystems. There could also be some sort of log on the FS and then when it is mounted, the host system would not need to scan it but could just read the log and "catch up" on the inode linking changes (When do we clear it, though?). Bottom line is the underlying FS would need to be modified in non-trivial ways and it would only work across compatible filesystems.
    – Rolf
    Feb 20, 2018 at 12:54

The root filesystem can be made up of several filesystems; /usr/local might be mounted on a separate partition and /home might be on another partition on a networked disk somewhere else. In this case, a hard link for /usr/local/bin/git (for example) may not be created outside of /usr/local, because it would span filesystems.

The reason for this is that the inodes are allocated separately for /, /usr/local and /home (again, in this example), and when you create a hard link you really just make an additional name for an inode.


A single inode number use to represent file in each file system. All hard links based upon inode number. File system reference link here .

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .