Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
We do often include affiliate links to earn us some pennies. See more here.
image

Here is a tip for the Linux nerds out there who want to be able to have multiple distributions (like Fedora, Ubuntu, and Slackware) installed on their computer, on different partitions of their computer's hard-drive, but would also like the freedom and simplicity of only using one storage location for their Steam games. (If you're unaware of what Steam is, please see this link. I'll also be the word "distro" to refer to a 'Linux distribution', which is used interchangeable in practice.)

The good news is that this is quite easy to do. I have tested and confirmed this myself, and this document reflects my actual set up on my PC, so I know it should generally work for most people's situations running multiple Linux distros on the same computer.

However, be aware: I am not quite sure if doing what I am about to suggest would work well for sharing the same Steam game data between a Linux and Windows partition (which may be problematic, since they use two different types of disk file formats, such as NTFS/FAT vs. ext4/ext3). So, if this is your goal, then please stop reading and look elsewhere. Sorry.

Okay, back to the Linux-to-Linux sharing of Steam files... But, please understand, the best way to accomplish this goal is to install the Steam client separately on both of your Linux distributions, then you will later share the actual game files (which takes up the most space). Yes, you'll have two copies of the Steam client (one on each Linux distro), but this is because each distro typically has variations on how to properly build/run the Steam client (because of different directory structures and so forth).

Therefore, with this in mind, you need to do the following (and I will repeat myself again):

1. Install the Steam client on both of your Linux distributions. If you're unsure of how to do this, please first try searching your distro's software repositories for "steam". For example, for Ubuntu, all you need to do is type in "steam" in the Ubuntu Software Center. Or, if you have Fedora, you'll first need to enable the RPMFusion repository source and then type in terminal: su -c "yum install steam". For further details on either of these suggestions, please see Valve's instructions here. For me, I am running Fedora 20 (64-bit) and Ubuntu 13.10 (64-bit) on my computer, with each distro installed on its own partition. Therefore, as I just stated, I installed the Steam client, separately, in each distro. Okay, I hope my point was stressed enough here :-). Also, for reference, my Steam's version simply states, "Built: Feb 25 2014 (Steam package version: 1393366296)", but I assume future versions of Steam will work in a similar way.

2. Next, simply create or pick a folder some place where both of your Linux distros can physically read and write data to it (don't do anything yet, though). For me, I actually have a third partition, which I aptly called SweetData, to allow me to share data and documents and the like across my Linux distros. But, before I explain further, I will note that you should not need to have a separate data partition for this trick to work. All that matters is that each distro has the ability to see the common folder and can write data to it.

Additionally, since Linux is awesome (and more awesome than Windows in my opinion), usually there is no problem for two different distros to browse and share nearby partitions of an alternate distro. Depending on the distro, you may have to type in your administrator password to open up external partitions like this initially, but that's okay, you can still use such a location for the common game data storage.

However, I have another warning if you already have a working copy of Steam on one of your distros: The method I used to share my Steam games has the actual game files stored to a totally separate directory than where the client files are located. A typical Steam install only has one location created (which houses both the client and game data). So, before proceeding, please do yourself a favor and backup any vital game files or configurations now to a safe place (that is, if you have any custom files that may not be automatically stored on Steam's cloud), as you may need to uninstall and reinstall all of your Steam games (but not the client itself) for everything to work flawlessly. To uninstall a game in Steam, you first need to look in your Library, and on the left-hand menu you will right-click on a game title and then select "Delete Local Content...".

Alright, so for me (using my SweetData partition), I created a folded titled "1. Linux Apps" that has a sub-folder called "SteamWPL". You can create these types of folders manually, or you can have Steam do so for you. Both of these folders I am using were simply created and labeled as such only because of my personal preferences. For me, I like to prefix some folders with a number so that they are always listed first in a directory, and I use the "1. Linux Apps" folder for other program data that I might share between my two distros. The "SteamWPL" folder simply has my initials of WPL as a suffix to remind me that I created the folder, not Steam. Therefore, you do not need to create two folders, but I would advise you to at least create a folder similar to "SteamWPL" because if you ever run into problems later on, you know exactly which folders to move around.

Regarding the actual creation of the folders, I mentioned you can do this manually as you would with any other folder on your computer, or you can use Steam. It is probably easier to do this manually with your existing file browser GUI (e.g., nautilus) or with a terminal like Bash. In the Steam client, you can do this by clicking on the "Steam" menu on the top-left, and then click on "Settings", next select the "Downloads" section on the left-hand menu. From there, you'll see at the very top is a portion talking about 'Content Libraries' with a big button labeled "STEAM LIBRARY FOLDERS", click on this and then click on the "ADD LIBRARY FOLDER" button. You'll then use that to create your common data directory for both distros to use. See the screenshots below, as they showcase this area in the Steam client.

I will show you visually what these folder locations look like on both my Fedora 20 and Ubuntu 13.10 distros. They both are using the exact same physical data blocks on my hard-drive, but they appear different because Fedora and Ubuntu mount partitions differently (namely because, structurally, they are two very different Linux distros). Here you go:

Fedora 20:

image

Ubuntu 13.10:

image

As you'll notice, Fedora sees my SweetData game folder as:
/run/media/junktext/SweetData/1. Linux Apps/SteamWPL

Whereas Ubuntu says:
/SweetData/1. Linux Apps/SteamWPL

Again, they are both the exact same physical data blocks on my hard-drive, but each distro might be a bit different with where it knows how to reference these data blocks. (Also the "/home/junktext/.local/share/Steam" is actually a real folder that IS being used by my Steam client. But, for whatever reason, Steam shows it as using 0 bytes, but this is false. This is where a lot of the Steam client files are located, taking up to about 1 GB of space, for each distro. I believe Steam is simply saying that my game files in that location equals nothing, which is true. Essentially, don't worry about this weird aspect on the Steam client. Moreover, there is a slight difference in the amount of storage used shown on my screenshots of my SteamWPL folder. But, this is only because I didn't take the screenshots on the exact same day for each distro depicted, so there were game updates later on.)

Okay, I hope you got the gist. If you haven't done so already, go ahead and create your common game folder some place that makes sense to you. As a tip, you can create the folder under your primary Linux distro's partition (e.g., Fedora). Then, if you use Ubuntu for testing or if you switch out/overwrite the secondary distro often (to try out other distros), you'll know that your Steam game files are always safe regardless of what you do with your secondary distro.

3. Tell Steam to use your common game folder. You might have already done this if you had Steam create your common folder for you. Otherwise, if you manually created a folder, just open up Steam and then click on the "Steam" menu on the top-left, and then click on "Settings", next select the "Downloads" section on the left-hand menu. From there, you'll see at the very top is a portion talking about 'Content Libraries' with a big button labeled "STEAM LIBRARY FOLDERS", click on this and then click on the "ADD LIBRARY FOLDER" button. After you find the folder you want, make sure to click on the "SELECT" button. I have another screenshot below to show you what I mean:

image



4. Install your games in Steam. At this point, you can safely begin downloading all of your Steam games (from whatever distro you are currently in). From here on out, all of these game files will be stored to the folder you specified. Likewise, both of your Linux distros will be able to use the same files with no problems. Just remember to point your other distro's Steam client to this common game data folder. Also, bear in mind that if you need to type in your administrator/root password to access the common data folder location (such as it being stored on another partition), and if you have NOT fully mounted that partition (i.e., you rebooted), that if you attempt to run Steam it'll appear as though you have no games installed. All you need to do is mount that partition (open up your file browser and click on the partition's icon or use an automated method), type in the correct password, and restart Steam. I just say this so you don't call me a liar accidentally.

That's it!

If you enjoyed this tip or have questions, feel free to send me an e-mail at [email protected]. Also, you can follow me on Twitter at @junktext.

Boring Legal Footnote:

Warranty:
There is no warranty of any sort provided by this Geeky IT Advice article. I try my best to provide accurate information, so you should likely not experience issues as long as you follow my instructions correctly. However, in order to protect me from any potential legal suit, you are hereby informed that any data loss or computer system problems caused from you following my advice will be your own responsibility to fix. Although, you can e-mail me to alert me of any technical inaccuracies that this document might have and I will revise the information accordingly. Thank you for your understanding.

// Original Article: (http://www.junktext.org/geeky_advice/file_005.html)
// File #5
// Date: 2014-03-15
// By: junktext (William Paul Liggett)
// FYI: See the 'Boring Legal Footnote' for warranty and attribution notices.
// Questions? E-mail: [email protected]

Attribution:
Linux is a registered trademark of Linus Torvalds.
Fedora is a registered trademark of Red Hat, Inc.
Ubuntu is a registered trademark of Canonical Ltd.
Slackware is a registered trademark of Slackware Linux.
Steam is a registered trademark of the Valve Corporation.
Valve is a registered trademark of the Valve Corporation.
Windows is a registered trademark of the Microsoft Corporation.
Lastly, at the time of this writing, none of the above trademark holders are associated with junktext.org. Article taken from GamingOnLinux.com.
0 Likes
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
14 comments

minj Mar 15, 2014
So much text... For such a simple task.

As long as it helps anyone, I guess.
junktext Mar 15, 2014
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.
n30p1r4t3 Mar 15, 2014
Honestly what purpose does this serve the average user?
adolson Mar 16, 2014
I just symlinked ~/.local/share/Steam to a steam directory on another partition. I’m not actually dual booting, but this is another solution that should work…
Same here. Works great for sharing between SteamOS and another distro (was Arch, now Debian). Only caveat is the user id ownership of the installed data is 1001 for SteamOS, so I just use that on my regular distro as well, rather than change SteamOS (I want to keep it vanilla, no added repos, etc).
junktext Mar 16, 2014
Honestly 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 :-).
DrMcCoy Mar 16, 2014
Yeah, I symlink as well. Not to share the data between two distributions, but to have the data located in a different directory than the default inside the Steam folder.

Adding a new location in Steam would work, in theory. But for every game installation, the drop-down thing for the location always defaults to the default Steam location. So you have to manually change that every time. And you can't delete the default location either.

And you don't even need to uninstall any already installed games either. Just move the whole folder, and symlink it to the original position. Done.
junktext Mar 16, 2014
DrMcCoy,

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.
Xpander Mar 16, 2014
last time i had 2 linux distros (arch and mint) i just had both of them linked to same /home partition
ofc username and stuff had to be same then. but it worked great for me.. no issues at all.
both systems had exact same configs for every program by that and also steam worked without issues.

it was little more than year ago though
micmon Mar 16, 2014
This 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.
junktext Mar 16, 2014
This 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?
micmon Mar 19, 2014
>> therefore ~95% of your Steam games will work in sync
>> by both distros if you follow my advice

This is not true. A lot of games store files in ".<gamename>" or ".local/share/<gamename>".

At first I did something similar to what you did and I got burned twice:

1.) I played a game which syncs to the cloud on box 1 and tried to continue the game on box 2. The sync did to cloud did not complete which at the time I did not know (I found out later that Steam had a problem on that day). So after starting on the second box I was not able to continue and after quitting it also synced my old savegame to the cloud and later this bad savegame was synced to box 1 as well...

2.) I had run a newer version of the steam client on box 1 and when starting the older client on box 2 (because the package manager did not update steam on this box yet) it totally messed up the steam installation and I had to do a reset.

I also thing you did not understand my use case: I do not want to share between different distributions but different PCs running the same distribution. This way I can use my steam installation at my place and as well as at my parent's place.
DrMcCoy Mar 19, 2014
syncs to the cloud

Apropos: I frequently start the Steam client on three different machines: My Debian system at home, my Arch laptop and my Gentoo system at uni. They should all use the same Steam version. Still, cloud saving for game categories in my library, i.e. when I put a new game in a category, or move on game to a different category, only works sometimes. Is there a trick you have to do, to force a change to sync to the cloud?
krsq Mar 21, 2014
A better version, if you have network storage, is to place your steam library there.
I have 3 computers using the same steamlibrary over nfs, works perfectly.
junktext Mar 22, 2014
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.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.