What's the difference between ln -s and mount --rbind?

mount --rbind makes a recursive bind-mount; that is, the filesystem hierarchy mounted on /mnt/extra/home will also be accessible through /home.

In practice major difference between the ln -s solution and the mount --rbind solution is that with ln -s /home is a symlink while with mount --rbind it's a directory; this affects tools like find, df, test/[ etc.

Also, the ln -s will fail if /home exists, while mount --rbind will fail if it does not exist, or it is not an empty directory.

Mark's comment below is also important: ln -s needs a writable file system on which to create the symlink.

In this case both a bind mount and a symbolic link will work similarly for most purposes, but they do have important differences.

A symbolic link is a bit more lightweight. You can have hundreds or thousands of symbolic links without it being much of a management problem. They sit in the filesystem rather than requiring special system-level setup.

Symbolic links can be backed up and copied correctly by tools like cp and rsync. That is, the tools can recognise and copy the symbolic link, ensuring that on restoration somewhere else the link is restored and points to the correct destination. It will all work "correctly" by default. By contrast, when backing up or copying a bind mount the mount will be treated transparently, causing the files themselves to be copied, which can lead to duplication if you also get the same files in their other location, and requiring extra work if you want to replicate the bind mount at the destination.

Symbolic links can be modified or deleted by any user who has access to the link, so it's easy to make it superuser-only, or open it up to a particular user. Bind mounts can only be set up or modified by the superuser.

If this sounds like a glowing endorsement of symbolic links, it is. They are a more straightforward way of linking between files and directories. You would use bind mounts only for situations where a symbolic link would not work, which may be fewer situations than you'd think. Most tools, including backup and sync tools, have a sensible default behavior for symbolic links and their treatment of symbolic links may be configurable. Bind mounts are transparent to such tools so you lose that flexibility and may lose the sensible behavior (for example as mentioned above, duplication of directories in your backups).

One more difference is that symbolic link is symbolic, i.e. it just references a path — a string of characters, and it's dereferenced each time you open a subdirectory/file in the target path. In contrast, mount --rbind behaves more like a hard link, for which the path isn't re-evaluated on each dereference.

This makes a difference in some scenarios like chroot. E.g. vsftpd chroots into the home directory of the FTP user account you log in. Thus if you put a symlink into that directory, vsftpd won't be able to dereference it, and thus the target won't be accessible via FTP. If you instead do mount --rbind, then vsftpd will just access that subtree as if it were really there, similarly as when you'd hard-linked a file there.