It is common to share /home mount and $HOME directories across multiple OSs, e.g. Ubuntu and Debian. The respective desktop environments (say, Ubuntu Gnome vs. Debian Gnome) try to share various configurations in $HOME/.config and $HOME/.local — this can cause conflicts and confusion. E.g., the same fonts or themes may not be available on both OS installs. Different extensions and their versions may also create a mess. Is there a way to avoid this problem, short of creating a separate $HOME for each OS and then perhaps symlinking a shared "real" home directory from those?
5 Answers
If you are sharing the same $HOME
, then it is up to you to make sure that works as expected. If both systems are using the same desktop environment and you have different versions of extensions etc., then that will indeed cause problems. A simple workaround is to use a different desktiop environment on the two systems so the settings don't overlap.
Although it is indeed common to share $HOMEs across distributions, that was much simpler a few years ago when there were fewer desktop environments around and most settings were about the shell and not the GUI. You can still do it, but you do want to be a bit more careful and try to avoid situations where the two systems have different config options. So install the same themes on both systems (this should happen automatically if they both have the same GUI and version), make sure you install the fonts on both systems and so on. As long as you keep them more or less in sync, you should be able to minimize the issues.
To make it 100% robust, however, you will need to have the configurations separate. One trick would be to move your config files and directories to another place and then symlink them depending on what system you load. For instance, you can have a partition that is only mounted by Ubuntu and one that is only mounted by Debian and store your ~/.config/
and various ~/.foo
files there. Then, in your $HOME
, you replace all these with symlinks to /mnt/dynamicallyMountedDrive
. You set up the two systems to mount either one or the other partition to /mnt/dynamicallyMountedDrive
and that means your symlinks will always point to the right setup for the right OS.
This way, you still have your actual data shared between the two systems, but the configurations are separate.
-
Many thanks for the suggestions. I should clarify a few things. For years I moved from Debian to next Debian with shared $HOME without any problem. Even for Debian (12) and Ubuntu (20.04), the limited set of applications I use are working fine with a single shared config area. Only some Tweaks and Extensions are misbehaving. I am not going to move back and forth much, so hopefully the conflicts will fade as I move back to Debian for some time. May 16, 2022 at 17:04
I used to love doing this, but stopped when I had data problems.
If one system sharing the $HOME is newer than the other, or just you have different versions of software; problems can occur. An update in evolution
or the GNOME-MUA on one of my systems made a newly received email invisible to the other OS sharing the directory; as it had an older version of evolution & thus ignored the way the newer version stored mail...
If both OSes are running the identical versions you shouldn't have issues, but if not - you need to check all apps versions on each OS using it can cope with versions of file for the other versions you're using, otherwise risk issues.
You also should avoid newer features in newer versions (it was my testing out a new feature that caused evolution
to alter how it stored mail creating my problem). I've used my problem as an example; but I've had other problems with other GNOME apps too with sharing, so I stopped doing it.
I now use a network share & the apps I know are safe share data on that share (ie. *on an application by application basis where new features are tested by me first with versions I use; with a shared $HOME all apps will be sharing data thus it much more homework).
-
3FYI: It took me weeks as I recall to discover my issue.. I was unaware I wasn't get all email when using the older email client; but people were telling me I'd respond to some (if I was using the newer OS/client when email came in) & ignoring others (if using the older OS/client thus email was in database but ignored by app). If I share data between apps my data-checking is now more complete on newer versions, as if you don't you risk issues like I experienced or tried to document here. Problems don't look good professionally..– guivercMay 16, 2022 at 22:48
For sure, sharing home folders between two distributions is not common. It can be done, and it is done on server systems, but it involves taking precautions in the startup files, that then may need to check the currently running version to activate the corresponding settings (thanks to doneal24 for pointing this out).
The reason is that configuration data is not guaranteed to remain the same between different versions of applications that come with different distributions. It will work in many instances, but it may not work in some others (e.g. Gnome Shell extensions): there just is no guarantee for it to work.
Thus, you need to keep user configuration data separate between distributions. If you want to mount the same data volume to different distributions, which is OK, you need to have different user home directories, each for use in only one distribution.
Sharing user files (documents, pictures, ...) between distributions is not a problem. These, you can symlink to make the data equally accessible from both distributions. You could then set up the permissions sufficiently liberal so users with a different UID can access the data, but a better approach will be to assign each of the users on the different distributions a same UID. You can even have the same login name: the name of the home folder of a user does not necessarily need to match the login name. While the GUI does not allow to set up, the useradd
and usermod
in contrast allow full control on the user's login name, home directory, uid, etc.
-
An application (say, Thunderbird) may change config and data file format even during the lifetime of a single OS release. Reputable applications will at least upgrade, if not allow some range of software versions to use some range of format versions. So this question is not really about OS or DE per se. Indeed, anyone sharing $HOME/.dotdirs is asking for trouble, and must handle such cases on their own. Point well taken. May 16, 2022 at 17:12
-
In a server environment, sharing
/home
across different environments is common and does not generally present problems. Having a.profile
that checks the OS and sets variables based on the result is easy. I've shared/home
across REL and Debian environments along with Irix and Solaris for years with no problems.– doneal24May 17, 2022 at 18:39 -
@doneal24 thanks for pointing this out - I updated my answer to reflect this.– vanadiumMay 18, 2022 at 6:31
While it can be considered common for people to link the $HOME directories, I would recommend looking for and removing the different things that you have installed on the two OSes.
It seems that there are conflicting packages installed.
This link may provide some helpful insight to your dilemma.
I would like to provide a completely other idea.
What about setting XDG_CONFIG_HOME
, XDG_DATA_HOME
. XDG_STATE_HOME
, XDG_CACHE_HOME
depending on the system.
For example, on Debian put this in /etc/environment.d/99xdg-debian.conf
:
XDG_CONFIG_HOME=.config_debian
XDG_DATA_HOME=.local/share_debian
XDG_STATE_HOME=.local/state_debian
XDG_CACHE_HOME=.cache_debian
I have not tested it in depth, but a short test showed it works.
In case you want to share e.g. cache among the systems, just don't set XDG_CACHE_HOME
.
See: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
-
Firefox and Thunderbied have trouble with modified XDG settings. bugzilla.mozilla.org/show_bug.cgi?id=735285 Google Chrome and Chromium, even without any extensions, are very sensitive to version shifts and maxes out 1-2 cores when in the "wrong neighborhood". May 27, 2022 at 10:56
-
1I am sure there are some more programs where the developers ignore xdg. At least mozilla is working on this since 18 years. :-) bugzilla.mozilla.org/show_bug.cgi?id=259356– MarcoMay 27, 2022 at 11:57
./config/user_dirs.dirs
and it will be available on all Linux usingxdg
.