Steam should not use ~/.local/share/Steam for install game but /opt/Steam/SteamApps

[Ruthubuntu]

Steam use your /home for install all games.
Exactly in ~/.local/share/Steam/SteamApps.

The problem: Déjà Dup (https://launchpad.net/deja-dup) save by default all the /home.

Normaly, the software who don't use Software repository, are installed in /opt

[biltongza]

Being able to choose where games get installed would be immensely useful.

[RunningDroid]

@Ruthubuntu
The things Steam downloads are user specific so they should go in the user's /home by default.

[plytro]

This is similar to how windows handles it. The logged in user is logged into steam for their account and the games they download are tied to that user account in steam which is tied to the system user.

[biltongza]

I disagree. The GCFs for games go to the same folder regardless of user in
windows, and anything else goes in SteamApps/common anyway. Why should it
be any different in Linux?
On Dec 21, 2012 4:26 PM, "RunningDroid" notifications@github.com wrote:

@Ruthubuntu https://github.com/Ruthubuntu
The things Steam downloads are user specific so they should go in the
user's /home by default.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/218#issuecomment-11614908.

[Spongeroberto]

It would be silly for multiple users sharing the same computer to have to download games separately and update steam separately. Keeping the general files in one location (for example /opt/steam/steamapps) and the user-specific files somewhere in the home directory makes more sense to me.

[RunningDroid]

@biltongza ProTip: Saying "Why should it be any different in Linux?" is a very good way to start a flamewar. If you really don't know why, then you should learn more about how Linux is different from Windows.

@Spongeroberto I'm not sure how Steam handles the Steam Workshop downloads but doing it like that may cause an issue if one user has a game with lots of mods and another has no mods.

[originalred]

Could there be a way to symlink perhaps? I'd personally prefer the GCFs to be stored on my SSD (possibly in /opt/).

[plytro]

I'll actually backpedal on what I said. The packed and unpacked files should be downloaded to a common dir (/usr/shared maybe) then the I agree with what @originalred said, the ~/..../ should be symlinked to that common. Just because you have multiple system user accounts, doesn't mean they will be using different Steam accounts. It doesn't make sense for me to have 4 Steam accounts when we can all share the same account to play TF2 or whatever.

[JLimperg]

@originalred You can always symlink stuff yourself, if it's just about your SSD. And with the new option to select various different SteamApps folders (is this in Linux yet?), your concern has even been addressed by the client itself.

On topic: I agree that it is indeed rather silly to have gigabytes of executables in a home directory, possibly duplicated for several users. Programs that want to bypass the usual directory structure, such as Steam, do normally belong into /opt. Of course, this only applies to the SteamApps folder (and maybe some other dirs under .local/share/steam/), but not actual user-specific data.

As far as privileges are concerned, someone on the forums suggested a solution that I found rather intriguing. It goes as follows:

1. Create a steam user and group and make them the owner/group of /opt/steam/ and /bin/steam.
2. Set the SUID bit on /bin/steam. This means that Steam always runs with the privileges of the steam user, rather than those of the user who's actually executing it.
3. Now we have a situation where users cannot access /opt/steam/ directly, but Steam itself can. Additionally, users can add themselves to the steam group in order to be able to manipulate files directly.

As long as Steam does not request root privileges (which it shouldn't have to, given this setup), the SUID bit poses no security risk, since the steam user and group don't have any more privileges than a normal user. However, there might be issues with Steam not belonging to certain groups, such as audio or video. If this is the case, substituting the SGID for the SUID bit should do the trick.

[biltongza]

@RunningDroid that was not my intention at all. I'm just saying that they have an existing system that works and could work similarly on Linux as in Windows. Like I said, all the files required for games are kept in one directory regardless of the active Steam user. User specific files are kept in their username folder under SteamApps/. It would be a waste to duplicate these files if a new PC user logs in and uses the same (or even a different) Steam account. JLimperg has a great idea going. Keep all the content files in one place, and perhaps keep user files in the cloud maybe.

[RunningDroid]

@biltongza
Agreed, but like I said earlier, What if one user has a game + 10-15 things from the steam workshop installed and another user has the same game but doesn't want the things from the steam workshop?
Or is that already handled on windows?

@Ruthubuntu
Some people would consider backing up the Steam dir a feature

[JLimperg]

I just checked my Skyrim installation, and it seems that files from the workshop are stored in common/Skyrim/Data/, which is no user-specific directory. However, they could still be loaded or not depending on who is logged into Steam. It would certainly be interesting to hear a couple of words from Valve on what is supposed to be handled on a per-user basis and what isn't, given that the approaches taken in Windows and Linux so far are wildly different.

[biltongza]

@RunningDroid those items from the workshop won't show up in their games because you have to subscribe to those items I believe, and that is account bound. The files will stay resident though.

[Majkl578]

This relates to (and would be solved by) #50.

[biltongza]

@Majkl578 no, that is for custom game libraries. We are talking about the default installation path (I think).

[JLimperg]

A resolution to that issue would definitely be a step in the right direction, but it would not solve our problem entirely. Most users will not tinker around with custom libraries, therefore the default location should always be as sensible as possible.

[ghost]

Also, you can just disable the directory for deja-dup backup.

[nsg]

Agree, $HOME is not the correct place to store binaries. /opt sounds like the appropriate place.

[Ruthubuntu]

@ r2ethan2: That i do. But, i will be better if Steam install the game in /opt

[RussianNeuroMancer]

the default location should always be as sensible as possible

Right. For example many users keep little root partition for the system and big home partition for the rest stuff - if Steam starting to put games like Team Fortress 2 and Serious Sam 3 to /opt that may make problems for users with little root partition. They will have to resize root and home partitions or add additional Steam library on home partition anyway or create separate partition for Steam library or move whole /opt to separate partition, etc, etc, etc. This is much bigger problem than just disabling Steam directory in deja-dup or BackInTime settings, do you agree?

So at this moment default location is sensible as possible. I can't say I like it (for example in my opinion it's better to move whole Steam client under system package manager jurisdiction, not only Steam bootstrapper; there is also proposal to make Steam like Synaptic and provide all games as deb packages) but it's sane enough. The only thing lack at this moment - actual Steam Library support in Steam game installation wizard.

[biltongza]

Then perhaps asking the user where to install games by default when installing steam is the way forward.

[remcohaszing]

This is already possible.
Close Steam and move the Steam folder to /opt/

sudo mv ~/.local/share/Steam /opt/

Open steam and it will show a pop up asking you to select where you moved that folder, navigate to /opt and select the Steam folder. Now Steam will use that folder by default. :)

[JLimperg]

@RussianNeuroMancer That is a very good point. My own root fs doesn't actually have enough space to put TF2 on it. ;) And with many of the major distributions making the two-partition setup their installation default (for good reasons), we can't assume that the people using it are necessarily comfortable with partition tinkering.

Seeing how many caveats are popping up in this thread, the best solution may indeed be to ask the user before or during installation. Maybe also give them a basic distinction between 'multi-user' (/opt) and 'single-user' (~/...) setup for those who don't care where their games sit, including an indicator for how much space is left in the chosen location. (Basically a Windows installer, then, as much as I hate to admit it.) Obviously, this would imply a non-trivial restructuring of the installation process and may come with its own problems regarding integration into the usual package management.

Another idea that sprung to my mind in response to the partition size problem (and thus isn't particularly well thought-out): /home/steam as a central location on the /home partition. Makes me cringe and want to punch people, but it would provide the benefits of both worlds, so to speak.

[tobiasschulz]

@JLimperg
I'm right there with you. It's not enough just to port the steam code to run under Linux.

Most Linux distributions are Filesystem Hierarchy Standard (FHS) compliant and putting many gigabytes of binary data in a user's home directory causes A LOT of trouble with many common backup solutions, partition schemes and it's just a waste of disk space too.

A separate user with SUID rights would be a much cleaner and very common solution for this problem. Most system-wide programs that are used by multiple users use this approach. Not only server processes, but also audio middlewares, printing/scanning daemons, display managers, anti-virus software, virtualization software...

I hope Valve fixes this for the final release and ensures that the development was not a waste of time. It's okay for a beta release not to be compliant with common unix behaviour, but if they don't fix it Steam for Linux will just be a crappy port that won't become generally accepted by distributions and users.

[jeck-simons]

I Agree. The steam client should follow best practices and install software in the standard 3rd party destination, "/opt/valve/Steam/", or some variant.

[tr37ion]

The binary stuff of Steam should go to /opt/valve/steam/ with all game data and and Steam binaries. The user specific configurations of Steam and game settings can be in ~/.config/steam/[gamename]. Save files and similar things could go to ~/.steam/savegames/. Yet it is also possible to put the last two folders together in ~/.config/steam/[gamename] imho.

[dmromanov]

Running Steam from my encrypted /home/ is very slow.

[markstinson]

Remember, Steam is commercial software that works with several communities openly (hardware developers, FOSS, users, etc.) It has a very wide demographic and install base it needs to satisfy.

Since there's no hardware survey regarding partitions and mount points ...

We all can acknowledge that (though the metrics may vary widely) :

• some folks don't have very large / filesystems
• some folks don't have /home on it's own partition, let alone one that can grow/be resized
• some folks would rather follow FHS standards a little closer (use /opt/) but requires root to install
• users on multi-user systems won't necessarily have sudo rights to install Steam
• some folks will have redundant Steam installs due to multiple users (only in residences likely fully converted off using Mac/Windows ... and how many are those exist? really?)

Of the above, which users does the current install directories impact the most - us alpha geeks who'll hack & work around things, making symlinks, tweaking them to our satisfaction (like me) OR a common user of default Ubuntu (like my brother)

Regarding Ubuntu, is probably safe to assume the following:

• Common users new to Ubuntu (or even using WUBI) accept the installation defaults
• Common users probably use 1 large / partition not counting swap. They likely to do not have multiple mount points. So they'll have Gigs of space available to them.

Don't forget, it's not just about the Steam client either. All the games you play will have Game Saves. Some put them in your $HOME/Games/$GameName, $HOME/.$GameName, and some will save in the Steam Directories for Cloud Sync. This stuff is going to be all over the place.

So what's Valve to do regarding the client installation? Keep in mind, if they are delivering a Linux based Steam Box / HTPC later in 2013 as Gabe casually announced, it's going to be sized & configured for ease of upgrade, rollbacks, etc. and likely use the same Steam for Linux client we currently use.

For the moment, it appears Valve are going about things with the most common denominator in mind. And that should work for now since we are all testing a Public Beta (which is subject to change). Keeping things simple at first is probably a good move.

So instead of defending a FHS layout, can we get a few more "out of the box" solutions? Here's a couple of potential alternative ideas that might satisfy everyone (more spaghetti on wall to see what sticks):

Use case 1: Install where initially launched

Consider Desura.com's linux game client. It installs where ever it's first run from.

If you mkdir ~/Games && cd ~/Games; cp ~/Downloads/desura.tar.gz . ; tar zxf desura.tar.gz ; cd desura; ./desura it installs all its games, saves and all in ~/Games/desura.

However, you use you ./desura from /opt instead - that's where everything is installed

Use case 2: Use an AppCache - Leverage Zero Install (0install) techniques

I've been impressed with the 0install concept for years (it's been around for 9 years !! ) . Unfortunately, it's never really gained Distribution traction which is a real shame for all of Linux & FOSS. Thing is, it's practically tailored exactly for Steam client's Use Case. (Maybe Valve could take 0install to a whole new level of in practice usage.)

Basically, applications are installed into an appcache ( /var/cache/0install.net ) with any library dependencies local to the install as well.

This allows for multiple versions to be installed, dependencies are always met, access by all users of the system, everything is cryptographically signed & fingerprinted, no files are owned by root, is distribution agnostic and can target different OS binaries (Linux/Mac/Win on x86/AMD_64).

• http://en.wikipedia.org/wiki/Zero_Install
• http://0install.net
• http://0install.net/comparison.html
• http://www.osnews.com/story/24778/0install_1_0_Cross-Distribution_Packaging
• http://www.osnews.com/story/16956/Decentralised-Installation-Systems

[tobiasschulz]

In the File System Hierarchy Standard, there are specific directories for static and variable game data: /usr/share/games and /var/games.

http://www.pathname.com/fhs/pub/fhs-2.3.html#VARGAMESVARIABLEGAMEDATA

"Any variable data relating to games in /usr should be placed here. /var/games should hold the variable data previously found in /usr; static data, such as help text, level descriptions, and so on, must remain elsewhere, such as /usr/share/games.

Tip: /var/games has been given a hierarchy of its own, rather than leaving it merged in with the old /var/lib as in release 1.2. The separation allows local control of backup strategies, permissions, and disk usage, as well as allowing inter-host sharing and reducing clutter in /var/lib."

But as steam probably won't use /usr/bin and /usr/lib for executables and libraries, /opt/valve/steam/ is also okay for all binary data.

---

@markstinson
It may be true that most users that are new to Ubuntu and Linux in general will have one big partition and probably don't care about the FHS standard and the "unix way" to do things.

But later they will get more familiar with Linux and then they will realize that the way Steam behaves currently is more than "foreign" on Linux. It's - sorry Valve! - just crap and interferes with many well established tools and work flows on unix-like operating systems.

Most users don't care about any implementation details of any programs they are using and games they are playing, no matter what operating system we are talking about - that's no reason for Valve to do use a technically bad approach against their own better judgment. We are discussing about how a beta version should be improved, not about the things some kids who just want to play games care about - since they don't care about anything (related to software development...)

---

So, let's summarize:

It really doesn't make sense to install game binaries and media files to to home directory. Like @tr37ion said, something like ~/.config/steam/[gamename] should be used for game settings and savegames, but not for any kind of binaries or media files.

There should be a user called "steam" with a corresponding group and the steam binaries should have Setuid rights related to this user, like @JLimperg explained.

This would be a clean approach which is very common in almost every Linux distribution and other Unix-like operating systems. It also avoids problems with backup software, partition schemes and encrypted home directories (@dmromanov).

---

Remember, every operating system is different. For Windows users it's quite normal to install applications to any directory a user may choose in the setup wizard, and it doesn't matter if there is a huge steam directory in your home directory.

But at unix-like operating systems, such a chaos would be unthinkable since every single binary and library in the whole file system is registered in the distribution's package manager and there are open and transparent standards where different kind of files have to be installed to.

You could say that the installation directory falls under the responsibility of the user and that may be true on windows, but on operating systems where all other programs are packaged in a well-defined way, it's not enough to think that those who really care can create a symlink to another directory. It's the responsibility of Valve.

Is there anybody from Valve out there to comment these suggestions?

[ivan1986]

@Ruthubuntu issue 218 nor linked to this nohow - it's about normal use package manager

[tr37ion]

@markstinson Equally important is, that Valve actually brings an additional 'package manager' to Linux. At least for their own software pool. Therefore, I would prefer that they keep their repository in /opt/steam/.

Should Valve some day decide to create a Steam Daemon next to a FOSS client (#171) architecture, this issue might be obsolete.

For the time being, Steam might better fit into /opt/. Accordingly, it's better to keep the /$HOME directory free of binary files. It's the user's "home" It shouldn't be pumped up with non-personal-related files.

Sure if they are going to separate the core from the client functions in a daemon all of this and a lot more issues will be obsolete. Currently there is no move in this direction and certainly won't in the near future. It's a huge step from a software architectural perspective. Therefore, it's important to publish the final Steam version at least with the option to change the 'media and games' folder prior installation IMHO. As I read you can move the current Steam folder somewhere else, then restart Steam and it pops up with a question dialog for the location of the new games folder. ~ I read it somewhere - didin't verify it

[Ruthubuntu]

@tr37ion : "As I read you can move the current Steam folder somewhere else, then restart Steam and it pops up with a question dialog for the location of the new games folder". I write it 7 comments ago.
For Steam, when i change the file's location is like i have a new PC: they send you a code to confirm this new location.

[Ruthubuntu]

Another solution, that use XDG Base Directory Specification Usage who separate the user preferences and the user data : https://live.gnome.org/GnomeGoals/XDGConfigFolders

[slouken]

"Being able to choose where games get installed would be immensely useful."

This is actually in for the next update, and it works exactly the same as it does on Windows, where you can set up arbitrary directories for your Steam Library.

[tr37ion]

@slouken I currently can't remember how this was solved in Windows. Were the user's data in Documents and all the binary stuff in the Programs Folder/Steam?

[meden]

Just my two cents:

Linux is not Windows.

I don't mean to be harsh at all, but just point that any solution used in Windows does not necessarily apply well in Linux. Linux embraces UNIX philosophy, is intrinsically multiuser and has standards (which are de facto constraints, although not really enforced) on its file system hierarchy.

Please note that the /home tree could be easily remotely mounted (via NFS or CIFS) and storing large binary data in there could have a severe performance impact (well, to be pedantic according to FHS the /home/* paths could even not exist!).

To me, the cleanest solution appears to be the /opt/steam one, as pointed by @JLimperg in comment #218 (comment) and very well resumed by @tr37ion in #218 (comment). I would stress that the /opt/steam one is a FHS compliant solution and would get rid of data duplication (and consequent disk and network resources usage) in multiuser setups.

A little design&development effort today can save from a big PITA tomorrow...

[meden]

Forgot to comment on SUID/SGID thing. There is a catch to watch out: running the whole Steam client as steam user would create steam-owned files in the user home (well, you could use ACLs or something like that, but it would be way too complicated...). Using only the SGID would end with binary files owned by different users under /opt/steam. So a possible solution could be to have separate processes for GUI (which would be run as the current user) and for the installer/updater (which would be run as steam user and would take care of everything under /opt/steam). That's at first glance, I may have overlooked something).

[ivan1986]

@meden, now you have written an emotional post fanatic, take it easy :)
Not dispute that the /home/* may not exist, but $HOME exist anyway.
Just this is the only location that is accessible to the user to record and in most cases it will suit it. All user content must be written on your behalf - SUID bit for such a program is the security hole. All of the problems with many installations decides specify the path to the library, then it can be moved anywhere just in config.

[ivan1986]

What's wrong with the current solution?

[meden]

@meden, now you have written an emotional post fanatic, take it easy :)

@ivan1986 :) yeah, I should have used some emoticon... (and the optional /home/* thing was only a boutade...)
Well, I didn't mean to start a flame war, just to point to a better (possibly the best) solution for a specific platform, rather than keeping adapting Windows stuff to Linux world. Now it is still possible to make things well, durable and maintainable, when the project settles it will be much more difficult. Sorry if I have been misunderstood.

I can't argue much on being SUID a security hole in this specific case, but I agree with @JLimperg and I don't think so, because the steam user would be a normal unprivileged user, with rights only on /opt/steam (which could be even set as his home directory). Moreover, no one would write anything on user behalf if there is a separation between frontend and backend. And the solution proposed could be only transitional (and indeed a first step in that direction) if Steam decides for a FOSS GUI and a proprietary daemon (#171).

What's wrong with the current solution?

Well... mainly that I don't understand Cyrillic... :) If I understood well, it is the ability to set an arbitrary path for a game. This cannot work well in a multiuser environment and does not solve the multiplicated resource usage (apart the standards compliance, in which one may not - regrettably - be interested).

[ivan1986]

@meden Decisions about windows, I agree, so just a # 218 - use package for steam.
Still, game content is uploaded by users and managed client content, at least keep it in the user's home directory - a good solution by default.

Why this cannot work well in a multiuser environment?
We have a common repository for example /data/games and two users - in the settings of each user to install one way to store games - now'll test it on a virtual machine.

[meden]

We have a common repository for example /data/games and two users - in the settings of each user to install one way to store games

Well... It's basically what has been proposed: /opt/steam as common repository by default, but avoiding any conflict or security issue.

Why this cannot work well in a multiuser environment?

Just setting the same repository location by multiple user cannot work, IMO, because it would be not a real multiuser setup, and because _Linux is not Windows_™ and not everyone can do whatever he wants with the file system :) (please, notice the emoticon...).

Let me explain with a simple use case. Suppose there are two users, Alice and Bob, who setup their respective Steam client to share the same repository /data/games, just like you are proposing. Alice owns (pardon, has a use license for...) the game A and install it; Bob do the same with the game B. Now the repository situation is something like that:

/data/games/-|
             +-A    (owned by Alice)
             |
             +-B    (owned by Bob)

One day Alice also buys the game B. What now? The installation will likely fail because /data/games/B already exists and Alice does not have write permissions on it.

Let's relax ownership rules then, and give rwX permissions on the whole repository to all users of Steam client (so you have to create and manage a steam group), or worst extend them to everyone. Now Alice can install B, overwriting the already existing installation. In the best case Alice and Steam servers are wasting time and bandwidth. But in the worst case you just opened a giant security flaw.

Suppose that to launch B Steam executes /data/games/B/b.bin. The evil Alice has write permission on it and replaces it with the simpler script:

#!/bin/sh
rm -rf /home/bob/*

I'm sure Bob will really enjoy its next game.

I think such scenario is much more dangerous than using the SUID bit with an unprivileged steam user...

Now one can argue that a multiuser setup is a rare thing, but we all hope in a conscious big brother who does not want to share its 18 PEGI-rated games with the 11 year old little brother (and the evil home eraser here would be an intruder or a malware). Or we cannot ever know how permissive can be a school with its shared lab computers (and be sure there will be plenty of wannabe crackers).

[meden]

Another big issue just came to my mind: even not considering the security hole, what if Alice decides to uninstall B? Files will be deleted and Bob will have to reinstall it. Not fair at all. And that's because the "shared repository" installation is not a real multiuser installation, as I said: the two Steam clients does not know anything about multiple user. With a common package manager would be possible to keep a count of users using each installed game and actually removing it from disk only when all Steam users uninstalled it from their respective frontend.

[meden]

Is this considered solved (while it seems not) or a wontfix?

[ancow]

The new version allows you to select a path where it will install whatever game you're installing (I haven't actually tried this out, so I don't quite know how this works), so I assume it's considered solved.

[Ruthubuntu]

If i want add /opt i get this message:
"New Steam library folder must be empty". o_O /opt is not only for steam This message should suggest that i must create a folder in /opt, not very clear. So I create /opt/SteamLibrary.

If i want to remove the first library folder where Steam stock their file, i can't: "The default steam install folder can't be removed" Boring ...

I try a new install with Steam 1.0.0.20 (after rename all files)
I don't have any message during installation for a choice. There are always a ~/.local/share/Steam and only could add /opt/SteamLibrary if i want to create one (i do it) During a game install, they ask me where i want to install.

It's a good step, but why Valve don't choose by default /opt ??

[Ruthubuntu]

I see that TF2 don't ask me where i want install. Someone confirm???

[yaakov-h]

TF2 doesn't use the new content system, so assuming parity with Windows you won't be able to choose a custom installation directory for TF2.

[ivan1986]

@Ruthubuntu Games - it's user-controlled content.
What they are forgotten in /opt?

[Ruthubuntu]

@ivan1986 : Sorry, i don't understand your question. Do you explain ?

[ivan1986]

@Ruthubuntu, Why need install games in /opt ?
They installs by user whisout admin rights, by default - only in home

[MrSchism]

@ivan1986: /opt is the standard location for this sort of data in linux/unix filesystem heirarchy.

[ivan1986]

@MrSchism this files instal by root or by simple user?
files install per user - then in home

[MrSchism]

@ivan1986: http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

[ivan1986]

@MrSchism I read this

[Freso]

@MrSchism Read @meden's comments above. Installing per-user files into a system wide location is not a good idea - this includes games (some people may want to mod certain things for their games, games aren't aware enough to automatically save files to $HOME instead of install dir, etc.). If games were FHS compliant and would looks for mods, settings, save games, etc. somewhere in $HOME, then sure, the main binaries etc. could go to /opt/ - until they do, it makes more sense (unfortunately :() to install it per-user. But with the knowledgeable user having the power to make it place itself otherwise.

[Ruthubuntu]

@ivan1986: Of course if you don't use admin right. But it's better to use admin right to make an install.