You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal, Flattr and Liberapay.!
Latest Comments by junktext
Saints Row 2 is currently free on Steam, other Saints Row titles on sale
21 April 2017 at 5:33 pm UTC

Thanks for the info about the game being free to grab, as I've went ahead and got it on my Steam Library now! Also, even though it sounds like there are some glitches with the Linux port, I do appreciate that a Linux version exists at all!

Natural Selection 2 adds a new map and smarter bots
15 June 2016 at 5:49 pm UTC

So, NS2 is basically the main game I play these days as I love the FPS + RTS blend. Actually, for me on my Ubuntu 14.04 LTS laptop, I rarely have any crashes. I really have no complaints regarding the video/sound performance of NS2 like I used to about a year or so ago. Also, for those new to the game, you'll feel lost/noobish for the first month. But, stick with it as it gets more fun when you understand everything more clearly. Anyways, just my two cents.

HITMAN looks like it's coming to SteamOS & Linux
15 June 2016 at 5:34 pm UTC

Hell yeah, I hope this comes to GNU/Linux as well! I remember playing this on PlayStation ages ago and loved how it was a smart shooter game that required strategy to come out alive. Though, I agree that an always-on connection to the Internet for single-player games is a stupid idea. Nonetheless, I could see myself buying this game.

Natural Selection 2 has a major update, the Linux experience is quite terrible
25 January 2016 at 4:23 pm UTC

For what it's worth, I've been playing NS2 on Linux for like 6 months with no major problems. I'm on a ZaReason laptop with NVIDIA drivers, using Ubuntu LTS. So, I'm sorry to hear that other fellow Linux folks are having issues.

Sharing Steam Games On Two Different Linux Distributions
22 March 2014 at 2:26 am UTC

Thanks for the catch there, micmon, as you are indeed correct. So, I apologize for saying that 95% of games would work (it seems more like 65-75% now). There are many games that do not use the ".../SteamApps/common" folder for their save game data/in-game configs (although all games that run from Steam will store their main files here). I didn't realize how severe the problem was until I started doing further research.

I am currently working on updating my how-to to include instructions for this, but, unfortunately, I have found no simple method to easily do this for every single game that uses Steam. This is because each game tends to use their own made-up location that follows no standardized format. So, essentially, a user will need to make symbolic links (soft links) to each game that does not follow the standard Steam location. This is tedious, but easy thankfully.

For example, Project Zomboid uses the following location for their save game data/in-game configs: ~/Zomboid (although see my note below). Whereas Organ Trail uses: ~/.config/unity3d/TheMenWhoWearManyHats/Organ Trail/.

However, worse yet, it may not always be a good idea to share in-game configs across two distros. I believe this mainly affects indie-developed games and not the bigger named titles that have more programmers to find these types of problems. As in the case of Project Zomboid, my Fedora uses a certain video resolution that gives me a great full-screen experience, but if I share this same in-game config (using a symlink) with Ubuntu, I get an-almost-full-screen experience (the top menu bar with the Ubuntu clock and such shows up).

Therefore, in the case of Project Zomboid, I just have it share the save game location(s) which are not exactly the same as the in-game config (the save game files are in sub-folders). At least this works nice. However, Project Zomboid is still in beta (or alpha or whatever) and I cannot even launch that game in Steam directly, as I need to venture into a terminal and have it run a .sh (shell) file. This is both for Fedora and Ubuntu and it's been this way for a while with me. I do not need to do this for other games.

Lastly, as krsq mentioned, this idea should work the same across network drives (to include cloud drives). But, I haven't tested this myself, though I may update my how-to to also mention this as well.

Thanks again, and I'll make sure to give you a shout-out in the credits, micmon (and I'll mention krsq if I include the network access concept). I am trying to get the how-to updated by tomorrow.

Sharing Steam Games On Two Different Linux Distributions
16 March 2014 at 6:59 pm UTC

micmonThis only seems to solve the problem of game storage. The more interesting thing is to also share the savegames and settings which is easily possible on Linux. This way all of Steam can be put on an external drive and be used on multiple PCs.

Well, most games on Steam store any configuration (in-game) settings under the Steam folder designated as your default Download location, which is the location I utilize. There are odd-ball games like Organ Trail that stores some configuration details in a weirdly buried folder (~/.config/unity3d/TheMenWhoWearManyHats/Organ Trail). But, Organ Trail was not developed with Steam originally in mind, nor did they make full effort to make it to be configured easily in this regard. So, with Organ Trail, I need to venture to that weird configuration folder to even make it go to fullscreen mode in Linux (any distro), as you cannot do so via the game's GUI. So, I need to configure Organ Trail twice in both distros. I just want to remind everyone that Organ Trail in this situation does not follow the standard Steam file structure, therefore ~95% of your Steam games will work in sync by both distros if you follow my advice.

To repeat what I mentioned in the how-to, I advise you to not share the Steam client files themselves across two distros. This can lead to stability problems, simply because each disto manages things like their library files and core system programs (e.g., GCC) very differently (the Linux programming libraries, not the Steam 'Library' of games).

This is true regarding how Fedora and Ubuntu manage their distro as a whole. Fedora is more bleeding edge, so you usually have the latest of everything, but Fedora is not as extensively tested as Ubuntu. Likewise, Ubuntu typically has older libraries and core system programs. Just compare and contrast the repos between the various Linux distros, you'll see what I mean (and pick two distros different from each other, not Ubuntu and Mint).

Thus, even though this may be technically possible to do, most people today warn others to never share a /home directory or a program directly across two different distros (unless you compile and package everything yourself for such programs). Yes, there was a time where many said such a set up was good practice, but you are only asking for problems. Hence is the reason for my data partition that I called SweetData.

In the case of Steam, it may not be a big deal as the flagship .deb package created by Valve, for Ubuntu/Debian, gets repackaged into different package formats (.rpm [Fedora/RHEL], .tgz [Slackware], .pkg.tar.xz [Arch]) by lots of volunteers as Steam is a popular program. But you are depending on these volunteers to do so and, moreover, even if a new .tgz package may exist for Slackware, it may not get uploaded in a timely fashion to the Slackware repositories because these newer Steam packages often depend on other packages (and each Linux repo is normally vastly different). This may be a bad example, as I haven't used Slackware for ages, so they may have what Steam needs all the time, but the idea is valid since Valve does not maintain the other package formats, nor do they interact with any other distro (officially) other than Ubuntu. Also, you may get away with less problems with sharing Steam like this, as it does not have that many dependencies. But, I still warn you to not do this.

A better example would be regarding other common applications people might use, such as LibreOffice. If you share your LibreOffice configuration files between Fedora and Ubuntu, you will most likely have issues eventually. The LibreOffice version in the Fedora repo is newer and it is older in Ubuntu's repo. So, even the configuration files for LibreOffice, not the full program itself, could have complications as newer programs eventually switch to newer designs of their configuration files. It may not happen often, but like the famous phase illustrates, “The only constant in life is change.”

Moreover, if you directly share your latest Fedora version of LibreOffice, meaning the WHOLE program into Ubuntu (akin to the Steam client), I would be very surprised if LibreOffice would work correctly. This is because, on Fedora, this shared LibreOffice would be happy with its newer dependencies (which has MANY dependencies), but Ubuntu would not have these newer dependencies installed (via the default Ubuntu repos) and LibreOffice would likely fail to operate or run at all, as Ubuntu would be trying to reference newer library requests which may not have such programming functions defined in the older libraries.

So, what I am advocating (using LibreOffice as an analogy) is NOT to share LibreOffice Writer (the MS Word equivalent) directly between both distros, but to share your Writer documents themselves (.odt, .docx, .doc). Though, in the Steam client example, your game files are what takes up most of the space, not the client itself. Yes, you will lose an extra 1 GB of space to store another client on your secondary distro, but how much pain is this in today's sense of storage reality?

Sharing Steam Games On Two Different Linux Distributions
16 March 2014 at 3:41 am UTC


Hmm, well, at least in how I described the set up in Steam (meaning that you need to first uninstall all of your games, then create a common game folder, then just reinstall your games), that Steam will then automatically install any new game to that common game folder. You are never asked by Steam which folder you want to use, as Steam will simply use the new common game folder. I just tested this out again to triple-check my work, and Steam just quietly put the new game files where I wanted. I cannot speak for everyone, but this condition applies in my situation, again using two very different distros (in a dual-boot design).

I would assume that people may only experience what you describe, where a new game install goes back to the stock Steam location and NOT the new folder you specified, because that person did not uninstall all of their games (before creating and pointing Steam to the new common folder). Keep in mind the uninstallation aspect is a one-time ordeal. It doesn't matter if you overwrite your secondary distro and place instead, say Slackware, over Ubuntu. All that would be required in this fresh Slackware install is to get the Steam client running and then just point Steam towards the common game folder. Both distros would then use the same game data without issue. (Well, as long as the game files were not on the Ubuntu partition! Hah.)

So, in a reduced example, where a person only has one game, such as Half-Life 1, installed on Steam's default directory (the "~/.local/share/Steam" folder). This person now wants to install Natural Selection 2, while also wanting to get their all of their Steam games working in both Linux distros. Now, let's say this individual did not uninstall Half-Life 1 before pointing Steam to a new common folder (the "SteamWPL" in my example). So, when they try to install Natural Selection 2, Steam may very well install Natural Selection 2 to Steam's default folder (where Half-Life 1 is still residing). I do not know if this example holds true in reality, as this was not the configuration I described in the article, but my example is based upon how I am understanding your complaint.

Also, I agree that a symlink process could work, but I appreciate that Steam itself can be configured to provide this 'sharing' role directly. This way, there is no odd user/group ID issues as adolson mentioned (at least I don't think there should be such a problem). This feature that I utilize in Steam was not its intended purpose, since it mainly allows people to move large game files to just a different partition of the same OS (which sounds like you wanted), not necessarily for a dual-Linux system. In your case, you could have used my suggestion, but it won't benefit you much now that you already have your games installed and have a symlink in place.

I hope this helps clarify what I was trying to say in the how-to article.

Sharing Steam Games On Two Different Linux Distributions
16 March 2014 at 12:09 am UTC

n30p1r4t3Honestly what purpose does this serve the average user?

Oh, yeah, this isn't really meant for an average Linux user, since most people settle with only one distro. But, I tend to enjoy switching distros every so often, which I hope my article helps others to do the same. The greatest strength of the Linux community is all the choices we have.

It sounds like others have the same success with the symlink feature. But, that's Linux for you. There are many ways to do one task :-).

Sharing Steam Games On Two Different Linux Distributions
15 March 2014 at 10:44 pm UTC

Yeah, I hear you, minj. It is a bit long. I figured it was better to help explain certain points more fully to make sure nobody was lost and wouldn't fall into a trap by accident.

Livestreams & Videos
Community Livestreams
See more!
Popular this week
View by Category
Latest Comments
Latest Forum Posts