Mount a folder on a drive in fstab. Move?

Question

I'd like to make a temporary change to my fstab file so that my /home is on another drive. However, I don't want the whole partition to be mounted, but just a folder ("home") on that partition. I'm OK with the rest of the data being unavailable.

What's the canonical way of expressing this in fstab? I can't think of a way to do it in one command (as I can't reference a folder on a filesystem I haven't mounted). I think I should do a first mount and then move the folder to /home. But I don't know if I can do a move in fstab, haven't found it in man (and I don't feel like trying blindly because I only have ssh access to the machine right now).

For now I have a bind mount in fstab:

/dev/sdd1 /mnt/temphome ntfs defaults,errors=remount-ro 0 2
/mnt/temphome/home /home none bind

However this leaves /dev/sdd1 mounted in both points.

To summarize:

• can I do a move mount operation in fstab and if yes, then how?
• is that the right approach and if not, what is?

Thanks in advance.

Answer 1

I don't think you can perform moves from /etc/fstab. If you want to do that, add a mount --move command in /etc/rc.local. That leaves a time in the boot process during which the home directories are not available at their final location. Since these are the home directories, they shouldn't be used much if at all during the boot process, so that's ok. The one thing I can think of is @reboot crontab directives. If you have any of these, the home directories need to be available, so you should add mount --move to the right place in /etc/rc.sysinit instead (just after mount -a).

Using a bind mount is probably fine, though. What can go wrong is mainly processes that traverse the whole disk, such as backups and updatedb. Leaving the bind mounts in /etc/fstab is the least risky option, but you should configure disk traversal processes to skip /mnt/temphome/home.

Yet another possibility is to make /home a symbolic link. However this may cause some programs to record the absolute path to users' home directories, which would be /mnt/temphome/home/bob. A bind mount or moving a submount doesn't have this problem.

Answer 2

No, you can't do what you're asking. As you've noted, you can't reference a file in a filesystem you haven't mounted yet.[*]

However, there is a scheme that might work for you: a filesystem-in-file on the donor partition, mounted via the loop device. Consider:

# cd /mnt/temphome
# chmod 700 .
# chown root.root .
# dd if=/dev/zero of=temphome bs=4k count=1M
# mke2fs -j temphome
(answer yes to the annoying question)
# mount temphome /home -o loop

What this does is creates a 4 GiB /home filesystem that lives in a file at the root of the /mnt/temphome partition. You still have to mount the donor partition and leave it mounted, but only root can mount it or change its contents directly, including mounting /home via the loop device. Once you've mounted the new /home, however, normal users can write to that new filesystem because they're doing so through the kernel, which has the power to do that, a power controlled by the permissions in the loop filesystem.

If for some reason that still exposes the /mnt/temphome partition to more risk than you wish to accept, the best alternative I can think of is to use gparted to shrink the donor partition and use the space opened up to create a new temporary /home partition. When you're done using it, pop back into gparted, delete the temp partition, and re-expand the donor partition to use the freed space. This has its own risks, though: modifying partitions isn't 100% safe.

---

[*] Well, that's not entirely true. Occasionally you see trickery involving knowledge of the exact disk location (sector, head, track) of files in other filesystems. This is most common in low-level activities: hibernation, swap, booting... For this to work, you need a completely contiguous file (i.e. no fragmentation) that never moves, so that you can just start reading and writing raw sectors from and to an unmounted partition.

If you watch the trend of such things over time, though, you notice that they tend to become less popular over time, because of the various consequences. For one thing, defraggers tend to break such schemes. It's one reason /boot and swap are usually separate partitions under Linux.