6

I dual boot Ubuntu 16.04 and Windows 8.1. All of Ubuntu lives on an SSD, and the core Windows stuff lives there too, in a separate partition. The main User folders for Windows (Documents, Downloads, etc.) live on a separate hard drive.

I'm running out of space in Ubuntu. I'd like to move /opt and /usr/local to the hard drive. All the Q&A I've found about this, however, starts with the assumption that these folders are already mounted on a different partition, or that I can format the destination drive. Neither of these is true for me.

I don't remember exactly what I did when I set this computer up, but I do know the hard drive is accessible from Ubuntu (and is at /dev/sdb1, mounted at /media/steve/storage). Is it possible to do what I'm asking?

5
  • 1
    15.04 reached end-of-life in February. You should switch to a supported release.
    – wjandrea
    Apr 5, 2017 at 16:04
  • 1
    Since /opt and /usr/local contain program files, you may prefer to move your /home partition first, for the sake of speed. If so, refer to How can I move my /home directory to another partition if it's already part of the / partition?.
    – wjandrea
    Apr 5, 2017 at 16:08
  • Sorry I meant 16.04. And I don't want to move /home, that's the whole point of putting it on the SSD.
    – Steve D
    Apr 5, 2017 at 23:23
  • You can edit your question to fix the version number. As for /home, I don't follow.
    – wjandrea
    Apr 5, 2017 at 23:25
  • General warning: you should NOT move directories that contain production critical files that are needed to be started during boot. If there is any trouble with that other disk it wont mount possibly breaking your boot, leaving you with an unbootable machine where you need a live session or a grub resque. That spells serious trouble if that machine is a cloud instance or even a server that is outside your reach. The 1st act of cleaning up an SSD should be to move USER CONTENT to that other disk.
    – Rinzwind
    Apr 6, 2017 at 12:19

3 Answers 3

6

You can simply link to it:

  1. Move the /opt directory:

    sudo mv /opt /mnt/otherDisk/
    
  2. Create a symlink to the new location:

    sudo ln -s /mnt/OtherDisk/opt /
    

You will now have:

$ ls -ld /opt
lrwxrwxrwx 1 root root 5 Apr  6 14:23 /opt -> /mnt/OtherDisk/opt

As Rinzwind correctly pointed out in the comments, this can break your system if you move a directory containing files needed during boot. For example, you certainly don't want to do this for /bin. /opt should be fine though.

9
  • 1
    This is not a complete answer. You can't just sym link opt and expect everything to be happy. If the drive or partition that you sym link it to does not automatically mount then it causes huge frustrations. The actual answer is to change the destination of OPT in FSTAB. Apr 13, 2019 at 0:26
  • 1
    @JoshuaRobison there shouldn't be anything in/opt that's required during boot. If there is, then yes indeed not having it mounted might be an issue. On the other hand, it might also be a problem to mount the drive automatically since that would stop the boot when the drive isn't attached. Moving and linking something like /usr would be a horrible idea, but /opt should be fine in the vast majority of cases. In any case, there is another answer that suggests the (perfectly valid, as you say) fstab approach.
    – terdon
    Apr 13, 2019 at 11:49
  • This answer is not good. Lots of issues:, Where did foo come from, sym linking to root???. As @jushuaRobison suggested - Move the data from opt to new drive, and mount this new drive on boot (fstab). once I do this I will post the process below. Often I put the current hdd into another machine to get unchanged data off, and this way pretty much anything can be moved (using dd). That siad be very careful! Feb 13, 2020 at 23:31
  • @NZDev whoops, thanks. I must have been using foo to test when I wrote it. That foo should have been opt. Apart from that, please see my answer to Joshua above. Mounting on boot can have a different set of problems. You just need to use the right approach for you. However, I struggle to think of a case where moving /opt would be a problem. There may well be such cases, I just can't think of one. I am not saying you can do this for any directory in general, but /opt should be fine.
    – terdon
    Feb 13, 2020 at 23:51
  • Somewhat agree, unfortunately the question did not have enough info to determine the exact setup. He said existing HDD this could mean it already has data on it, which in that case your solution is fine for opt. My preference would be to move out home, opt, srv, var to disk space that works for the solution. My preference is if creating brand new space for something that is getting larger is to stand up a new drive/partition and then mount it with fstab, mounting can have problems, but it is a good skill and usually the right practice Feb 14, 2020 at 1:17
4

I second moving /home, but it's possible to do what you want.

If I understand correctly, you have two drives, one with ubuntu (and possibly some windows stuff) and one with the windows user files. What you would need to do is shrink the windows partition (while I have done this successfully many times, resizing partitions may lead to data loss, so back up your data), and that will free up room on that drive. You can use a program like GParted to resize partitions. Once done, you can take the leftover space and make a new partition (also done with GParted). Then you'll need to copy the contents of /usr/local and /opt over to the new partition (I usually do this part by inserting a live cd and mounting everything and copying). Finally, you'll need to edit /etc/fstab and tell it where to mount /usr/local and /opt.

The link given above on the steps to move /home are the same, so you can follow that guide for moving /usr/local and /opt. What you will need to do is resize the windows partition first.

1
  • 1
    Not /home/ but the user content (the directories) should be moved. So altering ./config/user_dirs.dirs
    – Rinzwind
    Apr 6, 2017 at 11:36
0

RISKY PROCESS, DATA CAN BE LOST! Make backups

  1. I used this approach on my raspberrypi (just now) with different linux os (raspbian).
  2. setup the existing partition in my case with the same permissions on the folder. It was the only partition that was already mounted to /mnt/existingpartitionfolder/.
  3. Copied with rsync all contents of opt to existingpartitionifolder $sudo rsync -avX /opt/ /mnt/existingpartitionfolder/. Existing data in the existingpartitionfolder would soon becaome part of opt.
  4. I prayed that my symlinks moved relative to the copy process and did not link to the old opt location. I believe -l does this which is included in the -a switch, and they looked ok???
  5. Adjust /etc/fstab entry from /mnt/existingpartitionfolder to /opt
  6. I had an nfs running on that /mnt/ folder so I also adjusted /etc/exports entry to point at /opt which would be the same logical location after reboot.
  7. rename /opt $ sudo mv /opt /optold (my backup)
  8. $sudo reboot now
  9. Everything came back perfect and intact, now just need to delete /optold (deleting the backup, or move it to new /opt) if the space is required, and test.

To do this on other top level folders, may not work if data is moving. The same approach can be taken by putting the HDDs into another machine or running a LIVE disk. Just be carefull with your UUIDs in fstab, and permissions of folders and files. If boot sequence fails it is likely your UUIDs in fstab(big assumption). If you need to copy whole disks use the dd command.

You must log in to answer this question.

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