PDA

View Full Version : Common /home folder



glennzo
22nd November 2017, 09:43 PM
I've been thinking for quite a while about using a common /home folder since I tend to boot several Fedora installs, CentOS, Mint, Debian etc. While it would be extremely convenient for me, what about configuration files? I could, at any given point in time, be running Fedora LXDE, XFCE, Workstation, or Cinnamon, or I could be running Mint Cinnamon, Debian LXDE, Voyager XFCE, Arch Linux ... The list is endless with me.

Having said that, in principle a common /home might work, but in practice I think not, at least in my case. Would anyone have thoughts or actual experience with this scenario?

srakitnican
23rd November 2017, 07:19 AM
Well you can try, if something breaks you can test with a brand new account.

I am using single home across Fedora, used it for Ubuntu in the past. I can say for sure that Calculator just disappears from Fedora 25, Gnome's dash when I boot into Fedora 26 or newer. I need to re-position it then. Other then that I haven't noticed any major issues.

glennzo
23rd November 2017, 12:22 PM
A few issues for you but basically doable. OK, thanks for the input srakitnican.

satanselbow
23rd November 2017, 01:20 PM
I leave a /home in the root of each distro but have the media folders {Documents,Music,Video,Downloads + addition custom folders for static data and http projects} on separate partitions and share then between installations with bind mounts.

Ensures different desktop environments don't clash but ensures my essential data is always available regardless of currently booted distro...

glennzo
23rd November 2017, 01:22 PM
I leave a /home in the root of each distro but have the media folders {Documents,Music,Video,Downloads + addition custom folders for static data and http projects} on separate partitions and share then between installations with bind mounts.

Ensures different desktop environments don't clash but ensures my essential data is always available regardless of currently booted distro...

Oh! Sounds more doable and seems to make better sense.

satanselbow
23rd November 2017, 01:33 PM
Oh! Sounds more doable and seems to make better sense.

Given that any given distro may have a different version or customisation to any given desktop it cuts the stress of, seemingly compatible desktops, mangling each others configs.

I tend to use different desktops on different distros anyhow, but there is obviously some xover with the various flavours of mate/cinnamon/gnome yada yada which can be problematic ;)

glennzo
23rd November 2017, 01:44 PM
Well then, here's what I've come up with.

Create mount points somewhere. In this case on a second hard disk.

mkdir /mnt/iso/Downloads
mkdir /mnt/iso/Documents
mkdir /mnt/iso/Pictures

Add lines to /etc/fstab

/home/gjohnson/Downloads /mnt/iso/Downloads/ none bind 0 0
/home/gjohnson/Documents /mnt/iso/Documents/ none bind 0 0
/home/gjohnson/Pictures /mnt/iso/Pictures/ none bind 0 0

I lieu of rebooting I've manually mounted all three. Looks good and no apparent errors.

ocratato
23rd November 2017, 02:03 PM
That looks like a workable solution.
However, be careful if you are using a rapidly evolving application. It could update a document to a form not understood by older versions of the program.

satanselbow
23rd November 2017, 02:31 PM
This is what I run with - as said media folders spread across multiple disks with a partition each. You obviously need to copy the contents of /etc/fstab to each distro ;)



# DOCS uuuuuuu-iiiiiiii-ddddddddd

# mount LOCAL-DOCS in /mnt then bind folder to $HOME/Documents
# /dev/sda8 (Lenovo) LABEL=LCL-DOCS
UUID=uuuuuuu-iiiiiiii-ddddddddd /mnt/DOCUMENTS ext4 rw,relatime,noauto,data=ordered 0 0
/mnt/DOCUMENTS/Documents /home/username/Documents none defaults,bind 0 0


uid / username changed to protect the guilty :P


I can't actually remember why I have a mount and a bind... there was a good reason... I think... though it may now be moot O_o There is a very good reason but not got time to test breakage potential as at work currently.

rclark
23rd November 2017, 06:12 PM
Doable, but as above there are adjustments. Another one is the user id. I've had to modify that moving to a another distro. I don't 'cycle' OSs frequently, so it a one shot for me. Our data is stored on the home server, so no biggie if something does get lost locally. Therefore all but my R&D machine have only one SSD in them. My desktop isn't that important anyway. As long as I can get to my apps, I am good.

satanselbow
23rd November 2017, 06:23 PM
Doable, but as above there are adjustments. Another one is the user id.

May not well suited to a machine with multiple UID/GUID - although this could be overcome with the judicious use of groups. What other "adjustments" are you playing with?

rclark
23rd November 2017, 08:41 PM
Off the top of my head the UID/GUIDs are the big one. I do have multiple users but only two, so not to bad. I adjust them to match the centOS 7 home server, so all machines have same nfs access to the files. If you don't match, you have big headaches (can't open, can't write, etc.). The other is gui environments. Even when going to say LXDE to LXDE, if slightly different versions sometimes there are things that don't work due to config differences. Applications can be stored in different places, or applications exist there, but not here. That sort of thing. You just have to 'sort' them out and your good to go. In my opinion, the best way to juggle multiple OSs is to use VMs, but that's just me. The host box's box shouldn't be swapped out unless it is needed for some good reason. For example, my new Ryzen system didn't run with LUbuntu at the time, so loaded Fedora 26 instead due to it's newer kernel.

lsatenstein
24th November 2017, 06:16 PM
Hi Glennzo
I have a solution (5 disks) that works for me. I chose a common disk partition from the 5 which I titled /scratch (sudo chmod 1777 /scratch)

I kept a minimal home folder in place ( ~ ), and moved the rest out to /scratch.

Whenever I wipe a distribution and install another over it, I run the following....


#!/bin/bash
if [ $EUID != 1000 ]; then
echo "only valid for usr 1000. You are not authorized to use this script"
echo "only valid for usr 1000. You are not authorized to use this script"
echo "only valid for usr 1000. You are not authorized to use this script"
exit
fi
cd ~

DIRS="bin Documents Development Documents Downloads Music Pictures Public Videos Templates "
cd ~
for var in $DIRS
do
rmdir ~/$var
mkdir -p /scratch/$var
ln -s /scratch/$var $var
echo ""
done

ln -s /scratch scratch
echo "ln -s /scratch scratch"
ls -l ~

Each of the above mentioned sub-directories is common. I have been doing this for 3 years, and there is no hitch.
What I did not move over, because of laziness is ~/Dropbox. I do have a /scratch/Dropbox that is not linked to the Dropbox application, but is a local collection that grows over time. When I put a file into ~/Dropbox, I copy one to /scratch/Dropbox.

Have more questions? By the way, I am entirely satisified with my approach.

I also have a /backup that is on a separate disk from /scratch. Once every two weeks or as needed, I do a copy of /scratch to /backup
using cp -ra /scratch/* /backup

.

lsatenstein
24th November 2017, 06:23 PM
My laptop has only 1 disk. I created a /scratch on the / partition and run the same script. What works for me on the Desktop also works for me on the laptop

Kobuck
24th November 2017, 09:35 PM
I can't actually remember why I have a mount and a bind... there was a good reason... I think... though it may now be moot O_o There is a very good reason but not got time to test breakage potential as at work currently.

I would be interested in learning what the bind accomplishes. I share a "Documents" and "Development" user directory between my Fedora and Debian systems. Currently I just mount a volume via UUID directly under my "/home/user/Documents" and "/home/user/Development" in the fstab of both systems. Its a dual boot setup so only one usage is active at any point in time. ( also only a single user )

I have been doing this for several years without detecting any issues, what am I risking??

lsatenstein
24th November 2017, 10:21 PM
The following is an example from one of my (up to 5) /etc/fstab. Each / folder has an entry /scratch (empty) and a /backup), allowing me to mount these two partitions on other drives.
I use UUID= and as noted, my cross reference is on the right, identifying the /dev/xxx and the label (I label every partition).

#
#
# /etc/fstab
# Created by anaconda on Thu Nov 16 11:58:07 2017
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
#<file system> <mount> <type> <options> <dmp fsck> <xref> <label>
UUID=bd5f219d-8f9f-4882-82e1-250c53ca8aef / ext4 defaults,noatime 1 1 #/dev/sdc6 sdc6Slash
UUID=8c3212c9-8ee7-473e-acd2-e61f2575b397 /backup xfs defaults 0 0 #/dev/sda1 sdabackup
UUID=6f277782-b798-47fb-8312-657bc9793cdd /boot ext4 defaults,noatime 1 2 #/dev/sdc4 sdc4Boot
UUID=910767a6-bf2b-4713-bdd9-f0937288bf37 /home ext4 defaults,noatime 1 2 #/dev/sdc7 sdc7Home
UUID=16ec4d08-cc8a-410e-8150-b26e9552dee9 /scratch xfs defaults 0 0 #/dev/sdb2 sdb2Scratch
UUID=54edfc6c-d31e-4dd2-9d36-18992094fada swap swap defaults,noatime 0 0 #/dev/sdc5 sdc5Swap


I normally add the /scratch and /backup in the anaconda partition setup pane.

If I fail to do it in the anaconda step, then immediately after the initial boot, I create the /scratch and /backup within / and use blkid/* to pickup the two partitions from the list. I reformat the
two blkid entries to the UUID format. All of 5 minutes and then followed by a simple reboot.

I wrote a program which I will gladly share. The program reads the /etc/fstab, formats output to a copy as shown. If I like the copy, I use it to replace the /etc/fstab. My program, fstabxref adds the /dev/xxx and the label. I will pass the source/executable to anyone who wants a copy. It runs as a regular non privileged program, except if you are using the lvm file system, when fstabxref has to read a protected lvm parameter file.

My $HOME (~) folder is truly minimal and is not shared. What is left within ~ following my method are the hidden files, eg firefox caches, and a few other hidden file stuff. If you use firefox sync or xmarks, or both, then all the systems can fairly easily be kept synchronized.

glennzo
25th November 2017, 12:23 AM
The configuration in post #7 is not going to work for me. The files are in the shared folders only as long as the OS is running. As soon as I reboot the files disappear from same.

I think Leslie's solution looks good. I'll give it a shot.

glennzo
25th November 2017, 12:36 AM
Leslie. In the script, I don't see where the folders are linked to the partition on another disk? I looks like you create /scratch under / and then do some linking of all of the typical folders normally found under /home/username, but linking to the common partition? Am I not reading the script properly?

satanselbow
25th November 2017, 01:26 PM
I would be interested in learning what the bind accomplishes.

I've been playing russian roulette with fstab this morning... I can't immediately give you a sane answer as to why I mount then bind... may have been a long resolved mount bug... may have been a permissions thing (I am mounting each partition below /mnt - which is somewhat different to mounting in userland)... dunno... I'm probably just going a long-ass way about it and it ain't broke so I ain't fixing it :P

... may even have been a throwback to when I ran with a separate /home partition... nope... not a clue...

I did come across this article (https://unix.stackexchange.com/questions/198590/what-is-a-bind-mount) which clarified a few points along the way ;)

Kobuck
25th November 2017, 02:00 PM
I did come across this article (https://unix.stackexchange.com/questions/198590/what-is-a-bind-mount) which clarified a few points along the way ;)

Thanks for the link, good info :)

I totally understand the " ain't broke don't fix it " position. I will probably continue my approach as well.

I noted two interesting use cases in my note book. 1) Bind would allow remapping of GUID:UID 's when bringing traveling disk's into your system 2) Bind would allow remapping of /home directories to a separate shared disk volume without the need to create partitions for each of the directories you want to share. You could just create a directory on the new disk volume for each of the /home directories you want to share then issue a bind to map/link each directory back to the /home directory.



I came away with with a better feel for bind.