My Kubuntu workstation has an SSD and an HDD. The SSD contains the Kubuntu installation, while I would like to use the HDD for general storage where drive speed is not a concern.

I have the HDD mounted via /etc/fstab using: UUID=... /mnt/hdd ext4 defaults 0 2

I created symlinks for some of my /home subdirs to the HDD using: ln -s /mnt/hdd/Downloads/ ~/Downloads

This creates the desired outcome - e.g. Firefox downloads will downloaded to /mnt/hdd/Downloads on the mounted HDD partition instead of the SSD. This is not the only use-case intended for this. The intention is for directories like Downloads and Documents to be stored on the mounted HDD, while appearing to be in their default /home locations (both to applications and to myself).

However, when I reboot, this symlink breaks with the following result:

$ ls -l ~
Downloads -> /mnt/hdd/Downloads/

$ ls -l /mnt/hdd/
Downloads -> /home/<username>/../../../../../mnt/hdd/Downloads

I'm not sure why /mnt/hdd/Downloads would turn into a broken symlink on reboot.

This is a fresh install with no other symlinks set.

Am I doing something wrong here?

Edit: After some experimentation, I've found that this behavior is not consistent. Sometimes a symlink will break, and sometimes it won't. I've had cases where out of 5 symlinks, only 1 or 2 will be broken on reboot.

  • Instead of using symlinks, why just go into the Firefox settings and set the download location as /mnt/hdd/Downloads? Nov 7, 2022 at 0:20
  • The Firefox example is just one use-case. I'd prefer the convenience of having my home subdirs in their default paths. Furthermore, if I modify the Firefox paths, then I also need to modify paths for every other program that uses my home subdirs.
    – Zach
    Nov 7, 2022 at 0:37
  • Then you need to edit the question to include that information as well as whether or not you have symlinks for other applications that write to /home and whether or not they are breaking. If that isn't the case, then there's no significant reason that you can't just edit the Firefox settings and leave the other ones alone. Nov 7, 2022 at 0:59
  • Edited to make the environment and my intentions more clear. I came here with a specific problem of my symlinks breaking and am seeking a solution.
    – Zach
    Nov 7, 2022 at 1:37
  • Consider using bind mounts. That's what I do for this. Nov 7, 2022 at 1:58

1 Answer 1


Something very strange is going on at /mnt/hdd/Downloads, if the output you pasted is correct.

Specifically the output

$ ls -l /mnt/hdd/
Downloads -> /home/<username>/../../../../../mnt/hdd/Downloads

This looks like the path /mnt/hdd/Downloads is a symlink to... um... start at /home/Zach, go back up to /home, got up to root ('/'), go up again, again... again... (which will just stay at the root), then navigate downward to /mnt/hdd/Downloads

So first off, it looks like /mnt/hdd/Downloads must have been created incorrectly, and appears to be a circular link to itself.

What do you get from mount | grep /mnt/hdd? If it shows your drive, then it seems like your /etc/fstab is working fine. If it's blank then your drive isn't mounted.

If the drive is mounted

Your previous Downloads are probably lost, sorry.

The best I can suggest at this point is to unlink /mnt/hdd/Downloads to remove the circular symlink and then re-create a proper Downloads directory with mkdir -p /mnt/hdd/Downloads (the flag -p is likely not necessary for the Downloads directory here, but may be necessary for other directories).

If the drive isn't mounted

Remove any and all files from the path /mnt/hdd/ (if the drive wasn't mounted, then that path is actually on your SSD, not on the HDD) using the commands sudo mv /mnt/hdd /mnt/hdd.bkup; sudo mkdir -p /mnt/hdd

Then run sudo mount -a and verify whether or not the drive is mounted now. If it's not, then you'll need to fix /etc/fstab.

Assuming things went well, you can then mkdir -p /mnt/hdd/Downloads as above.

The real problem

I have to do some inferring here, but the fact that you have a link of the form /mnt/hdd/Downloads -> /home/<username>/../../../../../mnt/hdd/Downloads looks very wrong.

You mentioned that you created symlinks by running ln -s /mnt/hdd/Downloads/ ~/Downloads.

The problemmatic path suggests you probably ran the ln command with the arguments in the wrong order at some point, or from the wrong directory at some point (e.g. ln -s ~/Downloads /mnt/hdd/Downloads).

Depending on when this happened, it could have placed a symlink at the path /mnt/hdd/Downloads on your SSD which would prevent the hdd from correctly mounting. In that case, follow the instructions for "If the drive isn't mounted"

You can get some more info about which drive a file is on with df /mnt/hdd/Downloads, but those details don't seem totally important to this problem.

One last note

This strange behavior doesn't look like it has anything to do specifically with rebooting Linux. If your ln command is being run by a script (at reboot or whenever), then you need to provide details about that script, as it is the most likely culprit.

  • Thanks for the detailed response. My output from mount | grep /mnt/hdd is /dev/sdb1 on /mnt/hdd type ext4 (rw,relatime), and I have no trouble accessing the mounted path directly - so looks like the drive is mounted properly. I haven't been running ln from any scripts either. Very simply, I ran ln manually for each of the directories using the format I specified above. I've been through this cycle of "Create /mnt/hdd/<dir>, create symlink, reboot, see that symlink is broken, delete broken <dir> in both /home/ and /mnt/hdd/, repeat" several times at this point.
    – Zach
    Nov 7, 2022 at 3:18

You must log in to answer this question.

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