Sharing a Steam Partition Between Linux & Windows

[☆ spongey ☆]

Like the Title says, I need help setting up steam to run the same Games (that are compatible of course) between Linux and Windows. I'm running Windows 8.1 (where the steam games were installed and i'm running Ubuntu Gnome 14.04LTS. I've gotten Write & Read Partitions and everything working, the only thing that i haven't figured out yet was how to get both the Linux and Windows Executeables to be in the Steam Directory. This is the error that gets thrown up when i try to launch any of my steam games. Also, the "Games" Drive you see mounted on the desktop is the drive i already have steam setup to read

http://i.imgur.com/cruWLDC.png

[sounds like a wooosh]

Hi there, spongeyperson!

The main problem for your task will be that both operation systems are using different executable files. They are not compatible. You can run them inside of an emulator or a virtual machine - but never directly. This will be the reason why a simple sharing that way just won't work. (There may be exceptions - idk - maybe with Flash/Java games… or when games _always_ deliver the executables for all operating systems - but that's hypothetical.

Second: sadly, although this emulator workaround exists (namely 'Wine' on Linux) You can not have all games of different operating systems in only one Steam client as normal Steam games!
The most you can do is creating 'external links' which works in a few cases - mostly it doesn't.

Valve, instead of relying on Wine introduced this streaming solution (in home streaming, right?).
But if you want to _start_ Windows games on Linux you need to use two different Steam clients (one for Linux native - one for Linux-Wine for the Windows-games.)

That's it in short I think… I hope you find your way to work your best solution out of this!
Good luck!

[R3450N]

This wouldn't really work mate; you need to understand that Linux and Windows are not only two different operating systems with different binaries for executing programs; but also different file systems with another way of managing read and write permissions and how data is redistributed. Am guessing you used NTFS (or FAT) for your Steam partition: gz on getting that working. But because there are many executables for one game, you can't have conflicting files within the same folder; otherwise Steam automatically resolves it. This is one limit to dual booting, and I personally can't think of a programmatic way of resolving the issue other than creating another folder within the partition dedicated to Linux games; or perhaps linking the .steam folder to its respective one.

[Static]

A third partition, formatted to FAT (which can be read by Windows/Linux/Mac), specified as your Steam Library Folder (in Settings, under Downloads). This is almost guaranteed to break various elements, so don't try it at home. That said, if I wanted to break it, that's where I'd start.

[thetargos]

You can actually get the same library to be shared across Windows and Linux games, the downside part being that depending on the site you store the games (for simplicity reasons, the Windows partition is the likely one) you may end up with a bit of a performance hit when the games load, due to increased CPU utilization due to NTFS and NTFS-3g being a userspace filesystem driver in Linux (which works beautifully, but does eat up some CPU cycles), so depending on the game you may notice increased loading times, and such.

Generally speaking, though, you're best off with games which actually may share some data across OSes (say same game assets, with different binaries and executables).

So for instance Source based games you can actually have both vesions installed, but the Windows version will use the hl2.exe excutables, and the Linux version would use the hl2-linux executable. The way to do it.

System Checkup and Setup

Make sure you have your Windows drive mounted at boot-up. Depending on your distribution, this usually is the case, however, you can make sure about this by inspecting the file /etc/fstab with any text editor (like gedit), bear in mind, though, that if you do require to make changes to the file you will need to open it as root or with administration privileges, like so:

sudo gedit /etc/fstab

What you should see in the file are basic references to your computer's filesystems, partitions and this does heavily depend on your distribution, for instance, on mine (I'm running Fedora 20 with a custom partition layout mine looks like so:

#
# /etc/fstab
# Created by anaconda on Sat Jun 21 22:05:37 2014
#
# 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
#
UUID=1359d5ff-c700-469d-a00f-cceb0eb602f0 /                       ext4    defaults        1 1
UUID=55220980-1941-4dd4-b337-9b789f6798b4 /boot                   ext4    defaults        1 2
UUID=0d4ed645-a01b-4898-97d4-aa6976e1505f /home                   ext4    defaults        1 2
UUID=f01fe93c-ed3b-440c-8233-7003aa53a27f /liandri                ext4    defaults        1 2
UUID=67704a57-34fc-496b-9a7f-de2a84dc4736 /rikers                 ext4    defaults        1 2
/dev/sdb1				  swap			  swap	  defaults	  0 0

I have my basic partitions set (/, /boot, /home, and two others for storage purposes, think of the mountpoints as their lables, and they actually match).Notice that those partitions created at system installation time, have a UUID, you can identify partitions and drives this way with the aid of the UUID userpace utilities or you can address them in their device-node notation (/dev/sd*), as I did with my SWAP partition, which I had to manually add, since for some odd reason Anaconda (Fedora's installer) wouldn't add it; you can also address a particular partition (provided there is no repetition in the other partitions) by label, so something like:

LABEL=WinDrive				/windrv			ntfs	defaults	0 0

Would also be acceptable for Windows NTFS partition whose label is WinDrv and the mountpoint (directory under /) is /windrv. Suppose you'd rather use the UUID approac, then you'd simply generate the UUID with the command-line utility uuidgen <device>, supposing, since Windows mandates to be installed on the first drive of the computer for it to properly boot, that your Windows partition is /dev/sda2 (because you have a hidden recovery partition); in that case this would be:

$ uuidgen /dev/sda2
9cf7908b-3700-48d0-8166-c4eda2ac1542
$ sudo gedit /etc/fstab&

And simply add the line:

UUID=9cf7908b-3700-48d0-8166-c4eda2ac1542 /windrv	      ntfs	defaults	0 0

The fourth, fifth and sixth columns of the file instruct the system what to do with the partition once identified and where it should be mounted, for example, what options, if any should the drive be given, like umask, group, etc. You can check all those options in a Windows NTFS mounted drive, assuming you already have one with the 'mount' command, note the pipe to 'grep' to filter the output, like so:

$ mount | grep /dev/sd
/dev/sda3 on / type ext4 (rw,relatime,seclabel,data=ordered)
/dev/sda2 on /home type ext4 (rw,relatime,seclabel,data=ordered)
/dev/sda1 on /boot type ext4 (rw,relatime,seclabel,data=ordered)
/dev/sdc1 on /rikers type ext4 (rw,relatime,seclabel,data=ordered)
/dev/sdb2 on /liandri type ext4 (rw,relatime,seclabel,data=ordered)
/dev/sdd1 on /run/media/gianni/WinDrv type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

Here you can see what are the default parameters established for my ext4 filesystems, and interestingly enough which perms are given to the NTFS drive. Usually since I have more than one user on my computer what I'd do is to copy those options and use them in fstab, with pertinent changes to group_id, as I make all users who have actually access to the drive part of a group, for which I create one and then add users to, for example in the uers and groups tool, I create the group win, so that all users part of this group are able to read-write to the drive, and all others are only allowed to read from it, but not make any modification to the filesystem, you can play around with these options if you like. The mountpoint in the example above is due to the fact that I mounted the drive while I was inside my session and double-clicked it in the Nautilus devices section of the lateral pane, hence the /run/media/$USER/ format.

Setup Steam to use a single library

So I'll assume you have Steam already installed and have run it at least once, so that all the pertinent configuration and "local" installation has been performed, and you can start tinkering around.

Steam creates a series of directories under your home directory for its configuration and games, namely .steam and .local/share/Steam, note the dot preceding those? This makes those directories "hidden" directories, they will not come up in Nautilus or the shell, unless you explicitly state so (ctrl+h in Nautilus or 'ls -a' in the command-line). For simple warming fuzzy feeling inside sake, I'll go with the command-line route, which is pretty generic for any Linux system:

1. Make sure these directories exist:
   

   ls -a | grep steam && ls -a .local/share | grep Steam
   .steam
   .steampatch
   .steampid
   Steam

   The .steampatch and .steampid are there because I have Steam running.
   
2. Go into the .steam directory, notice the SteamApps directory as well...
   

   $ cd .steam
   .steam]$ ls

   List the SteamApps directory under ~/.local/share/Steam, Fedora has an alias for the form 'ls -l' as 'll', which I'm not sure is present in other distros:
   

   ll ~/.local/share/Steam/SteamApps
   

   The contents of this directory will actually be many symbolic links to the appmanifest files in your ~/.steam/SteamApps directory, the idea behind having a unified library is that you will have all your games under ONE directory (SteamApps in your Windows drive installation) and LINK that directory to your Linux installation in such a way that both systems will have access to the same pool of games... A note of warning: Windows has no CaSe SeNSiTIviTY at all, and since Linux does, things could go south if Windows does make changes to files whose names may change to which the Linux version does not compensate for. You can save up to a file the output of the last command (so you can copy the links later in an easier way) with a trailing > to redirect the output:
   
   

   ll ~/.local/share/SteamApps > ~/Desktop/SteamAppsLinks.txt

   
   
3. Substitute SteamApps. Before making anything rash, and to allow for reversing the changes should anything go wrong, for the time being just rename the SteamApps directory to something like SteamApps_bak or something:
   

   mv SteamApps SteamApps_bak

   
   Now procede to create the link:
   
   

   .steam]$ ln -s /windrv/"Program Files (86)"/Steam/SteamApps SteamApps
   .steam]$ ls -l | grep SteamApps
   lrwxrwxrwx. 1 $USER $GROUP 35 SteamApps jul 27 14:55 SteamApps -> /windrv/Program Files (x86)/Steam/SteamApps
   

[/list]Go test the result in Linux, and once you have Steam open, you will have to make sure that Steam checks the games files and downloads any missing pieces (namely executables), by means of going into the properties of the game, right clicking the title from the list on the left, and then selecting the local files tab. It may take a while, depending on your drive's speed, and since this will most likely be in an NTFS formatted partition, it'll eat up some resources as well, and maybe take a bit longer, so be prepared for that.Hope it works out as well for you has it has been for me, albeit, with a limited selection of titles.~ Edit ~If all goes OK, you may not require to re-do the links in ~/.local/share/Steam/SteamApps, and you can finally remove the renamed SteamApps_bak directory (if within Nautilus, use shift+del to bypass the trash, or rm -rf SteamApps_bak from a command-line).I have this approach working with a third location for Windows Steam games played under Wine, with a "central games repository" in one of my storage drives, and links to the SteamApps under both the Windows installation under the .wine prefix and the .steam directory for the native client... I do not have native games installed under the wine installation, though, so I can't attest to the certainty principle that all files will retain integrity were it on a "true" Windows environment separated by a reboot.

[Static]

Fancy that. Thanks for the detailed info!

[Tux9656]

Another thing you could do would be to put your Steam library folder on a different computer via a samba/CIFS (a.k.a. Windows shared folder) share. Both Linux and Windows work very well with CIFS. The other computer doesn't even have to be a physical machine. It can be a virtual machine with direct access to a partition on your hard drive. You can put the virtual machine's hard drive image file on a FAT32 partition so you can boot it on both Windows and Linux. This method also works very well for accessing Linux filesystems under Windows.

[thetargos]

I wouldn't place a Steam's game library on FAT[32], though... and its inherently limited, corruption prone properties, but CIFS is also a good idea.