6

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?

9
  • 9
    No, it is NOT common. It's actually strongly discouraged due to the issues you correctly identified. And no, there's no other way than having it separately. May 16, 2022 at 13:55
  • 5
    @ChanganAuto yes, it IS common and has been for decades. It can cause problems like the above, but it works fine if you're careful and in any case is certainly common and done quite often. I did it for many years. I've kept the same basic $HOME and various files in it across various different Linux flavors over the years.
    – terdon
    May 16, 2022 at 14:13
  • 5
    @Rinzwind I didn't say it was a good idea, I said it is common. And it is, or certainly was, long before Ubuntu was created. The whole point of it is precisely to share the configuration between different systems. Yes, that can cause issues when they have different versions of things installed, but it can also be fine if you're careful. Doing it with different Ubuntu versions would be even worse, of course, they are bound to have conflicts there.
    – terdon
    May 16, 2022 at 14:41
  • 3
    Why even use a /home/ mount? Just take out the directories and put those on a shared partition. It can even be NTFS if you want to include Windows. There is a file for that called ./config/user_dirs.dirs and it will be available on all Linux using xdg.
    – Rinzwind
    May 16, 2022 at 14:48
  • 4
    @terdon the beauty of Linux: to each their own. Sharing home settings in my experience was always frowned upon. dconf will be a mess.
    – Rinzwind
    May 16, 2022 at 14:49

5 Answers 5

8

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.

1
  • 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.
    – user174626
    May 16, 2022 at 17:04
6

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).

1
  • 3
    FYI: 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..
    – guiverc
    May 16, 2022 at 22:48
5

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.

3
  • 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.
    – user174626
    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.
    – doneal24
    May 17, 2022 at 18:39
  • @doneal24 thanks for pointing this out - I updated my answer to reflect this.
    – vanadium
    May 18, 2022 at 6:31
2

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.

0
1

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

2
  • 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".
    – user174626
    May 27, 2022 at 10:56
  • 1
    I 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
    – Marco
    May 27, 2022 at 11:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .