Hi Folks,
So I’ll be setting up / rebuilding some of my systems in the next couple weeks and I’m trying to decide on an approach.
All of my systems have multiple distros installed and I multiboot between them depending on what I’m doing.
I always create 2 accounts: Admin & User (both same privs, just diff ids). “Admin” is always left with the defaults, and I only use it to debug and solve problems which may involve the “User” account. “User” is my actual day-to-day account.
The User $HOME currently sits on the main system partition and only really contains configs, bash stuff, scripts.
This main system partition is unencrypted. Debugging an encrypted system partition is (for me anyway) a royal pain in the tuckus…
All my actual data sits on other drives (which are encrypted).
What I want to do is place my “system” $HOME onto another drive/partition on my local machine (relatively trivial).
I would also like to put /var on another encrypted partition as well.
Now creating a “home” partition on install is easy. So is either creating a user’s $HOME directly on another partition/drive when creating the user account or moving it there afterwards.
What I’m contemplating doing differently this time is using the bind option in fstab at system startup for both $HOME and /var.
Thus the original system directories would still be there and on boot (after going through cryptab and fstab) the “actual” directories would be mounted on top of them.
And the “User” partition would a separate home dir for each distro say: /User_mint; /User_fedora; /User_gentoo; /User_openmadriva
Anything I should avoid? Ditch the idea? Watch out for?
Someone feel free to correct me, but from my understanding you don’t need a bind-mount for what you’re wanting to do, and it would arguably be the wrong tool anyway.
A bindmount mounts an existing directory tree into another directory, making it available in both places. So if you do mount --bind /mnt/drive/home/admin /home/admin (or the fstab equivalent), then the same directory would be available in both places. It’s important to note here that the directory you’re trying to mount has to exist and be mounted already. Bindmounts don’t involve a filesystem driver, they are an abstraction in the kernel. This means you cannot mount a partition containing the admin’s home directory this way. You would need to mount the partition first somewhere else, and then bindmount it into home.
So unless I misunderstood you and you actually have a directory you want to mount there, a bindmount would be the wrong tool to begin with.
What you probably want is mounting a partition (or subvolume, whatever) directly to /home/admin, which also “overlays” the existing directory tree with what is in the partition. The original directory tree is left untouched on the filesystem. This is essentially what OCI containers do when you mount a volume.
The thing with this is that I don’t see the benefit in doing it this way instead of just mounting the partitions there directly.
There are 2 scenarios you could do:
- Use the
nofail option when mounting, which is unpredictable when the mount fails for whichever reason, so it should be avoided
- Don’t use the
nofail option when mounting, which means that the boot will fail if the mount fails. Conversely this means that on each successful boot your mounted directories will always be there, i.e. the “system” directories as you call it will never be accessible to begin with. Unless you dismount the overlayed directories/partitions at runtime, which will probably result in all sorts of fun.
Thanks for chiming in. I did find this earlier this afternoon:
https://www.baeldung.com/linux/move-system-directories-separate-partitions
Which talks about it.
And yes, the dir has to already exist and you can get to it through multiple pathways. So a “mount –bind /mnt/drive2/foo /home/foo” would overlay the foo directory located on “/mnt/drive2/” (another physical drive) to “/home/foo”.
cd /home/foo
would thus actually have you go to the foo dir on drive2. And you’re right, you can’t mount a partition this way, only a directory
This is exactly what I want to do.
OK, this makes me wonder why though. Is it only to reuse an existing partition with the directories on it or do you have a reason why you’d want to do it this way?
Because I can’t really think of anything why this would be useful. The permissions are the same in both paths, so it doesn’t make it any less or more easy.
I guess it makes it easier to have only the one partition to encrypt that contains all the home directories rather than encrypting one home partition per user. But that also kind of defeats the purpose of encrypting them, no? One shared password to decrypt all of them? Unless you want to be able to access them across users.
But either way if that’s what you want to do I don’t see a compelling reason not to do it either, just find it a bit odd.
Well, I’m the only user (albeit with at least 2 accounts) 
. But I’m only moving certain ones over. If this was an actual multi-user system, or a client’s computer I’d (likely) set things up differently.
Though I do have 1 client where I did this approach (by creating his $HOME on a different drive at useradd). In his case, the machine has 3 drives. One system drive and the other 2 set up in btrfs raid 1 with his home dir.
In my personal case, it’s more related to encryption and backup. Typically I make a drive image of each system (mint, debian, etc) on the machine. Whereas the actual data drives (also encrypted) are backed up with rsync to a raid enclosure.
Then when something breaks (usually because I’m “experimenting” with something, I just restore the image. faster than debugging oftentimes.
Which is (naturally) when I remember all the symlinks, scripts, and aliases, that didn’t exist when I made the image; and other little things like that.
Whereas on the encryption side, using luks on the root partition can become something of a pain. And the /home and /var directories will often have data you’d want encrypted, but using something like encfs is an even bigger pain (for me at least). In this case, it’s more about making it harder for the piece of 
who broke into my car and stole my laptop, if that should ever happen.