Binding mounted SSD under /home using fstab, can you use the /proc/mounts path?

Question

I have three SSDs in my system. The first, physically in the hardware (if that matters), is my Windows installation, the second my Ubuntu 20.04 installation, and the third is an NTFS storage drive. I am attempting to more easily interact with the storage drive.

The behavior that I would like to implement is that under /home I have a directory which "looks like" my storage drive. That is, if I open the directory it displays all the same sub directories and files present on the drive; any changes made in this directory automagically simultaneously happen on the storage drive/data. This way I can work with /home instead of having navigate into another directory.

I am reviewing this Ask Ubuntu answer and it seems to provide a partial solution. The original questions asks how to ensure a bind stays present after a system reboot. The answer provides the solution to enter an fstab entry akin to

# <device>                                 <dir>                 <type>  <options>                 <dump>  <pass>
UUID=288a84bf-876c-4c4b-a4ba-d6b4cc6fc0d2  /mnt/device            ext4    defaults,noatime,nofail   0       2
/mnt/device                                /srv/binded_device     none    bind

where the device, addressed by its UUID, is mounted to /mnt/device and then /mnt/device is binded to /srv/binded_device. Though I can't quite gather how to apply this to my situation.

So my device /dev/nvme2n1p2 (an NTFS partition spanning the entire drive) is mounted to /media/<user>/Storage in /proc/mounts

dev/nvme2n1p2 /media/<user>/Storage fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0

But I can also gather both the UUID and PARTUUID via sudo blkid

dev/nvme2n1p2: LABEL="Storage" UUID="8E7C25407C252485" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="880d93fe-65da-45d9-b7ec-322bc51cdd52"

EDIT: I just realized other Ask Ubuntu answers provide a solution to this first question.

My first question is if I were to follow the pattern presented by the linked answer should I use the UUID or PARTUUID in fstab?

Like so (in the case of using PARTUUID)

# <device>                                 <dir>                 <type>  <options>                 <dump>  <pass>
UUID=880d93fe-65da-45d9-b7ec-322bc51cdd52   /mnt/storage         ntfs    defaults,noatime,nofail   0       2
/mnt/storage                                /home/StorageBind    none    bind

Second and third, again following from the linked answer, where to and what should I call the mount location? Can I just call it /mnt/storage? Should I alter the type in fstab to be ntfs, what other options should I include/remove?

Rather, can I just address the drive in fstab as the mounted location from /proc/mounts? Essentially allowing me to bypass the first three questions..

Like so

# <device>               <dir>               <type>  <options>  <dump> <pass>
/media/<user>/Storage    /home/StorageBind    none    bind

Additional questions that may influence the answer for my specific use case (though I think the question still has general purpose merit).

This storage drive contains some code which produces various result files. The code must be ran in a Docker container that can only be run under a linux installation (nvidia-docker), though I am still also inextricably linked to using Windows for various administration tasks on the results. In the past, or when not using the storage drive, I will use Docker's bind-mount option to mount a host directory within the container (one containing my codebse).

So I am specifically worried/interested if this bind works as desired and described above, would I be able to further docker --mount/docker --volume the bind to the storage drive?

docker <...> -v /home/StorageBind/<codebase>:/code

score 1 · Accepted Answer · answered Mar 10 '21 at 12:27

I do not see the issue and the reason of the complexity for this question.

The behavior that I would like to implement is that under /home I have a directory which "looks like" my storage drive. That is, if I open the directory it displays all the same sub directories and files present on the drive; any changes made in this directory automagically simultaneously happen on the storage drive/data. This way I can work with /home instead of having navigate into another directory.

That is exactly what you simply achieve with a symlink. Creating a symlink under /home that points to the mount point of your storage drive will exactly do that.

Symlinks are simple, and the first option here. They work as regular folders for any practical purposes. For special requirements, where a symlink does not cut it, there is also the mount --bind option, allowing to bind any folder on a mounted volume to a different folder. Thus, you can effectively mount your storage drive in a second location under /home if you wish so.

The complexity of the question initially arose from this Unix&Linux StackExchange question and its first answer (https://unix.stackexchange.com/q/49014/58449). Though, after re-reading it maybe I misunderstood what the question actually was. The accepted answer notes "A symbolic link cannot be a mount point.". I think the user wanted to "go in reverse" from what I am asking. In the end though, after reading that question I researched solutions involving mount --bind instead of ln incorrectly thinking anything that is mounted must be bound and not symlinked. — KDecker, Mar 10 '21 at 15:17
A symlink cannot be a mount point but you can symlink to a mountpoint. Indeed, sometimes it gets confusing, but I am glad it is resolved. — vanadium, Mar 10 '21 at 17:48

Binding mounted SSD under /home using fstab, can you use the /proc/mounts path?

1 Answers1