ValveSoftware
SteamCMD ~/.steam or ~/Steam
Your system information
- SteamCMD
Please describe your issue in as much detail as possible:
I am the developer of LinuxGSM and I am trying to resolve issues with Linux ARK server mods
When installing SteamCMD sometimes it uses ~/.steam and sometimes it uses the ~/Steam directory. This is problematic as game servers like Ark use these directories to store workshop mods that need to be symlinked. If SteamCMD just randomly decides either of these directories it is a pain to figure out which one to symlink.
I am currently assuming that it might be the version of steamcmd that is downloaded from the ubuntu repo or direct download. For example, Ubuntu 18.04 has ha 2013 package as Ubuntu 19.10 has a 2018 package.
I have done some testing but I can't seem to lock down how it decides to use either of these directories.
Steps for reproducing this issue:
apt install steamcmd steamcmd
Will be either of the following
Redirecting stderr to '/root/.steam/logs/stderr.txt'
Redirecting stderr to '/root/Steam/logs/stderr.txt'
Linux Mint 19.3 Cinnamon version 4.4.8 Kernel 5.3.0-42Generic
As discussed on Disc via @Sparwhawk mine is going to .steam/steam/log with the text, sh: 1: /home/mint/serverfiles/Engine/Binaries/ThirdParty/SteamCMD/Linux/linux32/../ubuntu12_64/gldriverquery: not found sh: 1: /home/mint/serverfiles/Engine/Binaries/ThirdParty/SteamCMD/Linux/linux32/../ubuntu12_32/gldriverquery: not found sh: 1: /home/mint/serverfiles/Engine/Binaries/ThirdParty/SteamCMD/Linux/linux32/../ubuntu12_64/vulkandriverquery: not found CApplicationManagerPopulateThread took 0 milliseconds to initialize (will have waited on CAppInfoCacheReadFromDiskThread) CAppInfoCacheReadFromDiskThread took 92 milliseconds to initialize
Further info the server starts but is never viewable in the list. However the minute I remove the mods it pops up within 3 minutes on the list.
Debug info:
4.5.1-0+UE4 7038 3077 404 10 [S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed. Setting breakpad minidump AppID = 346110 Redirecting stderr to '/home/mint/.steam/steam/logs/stderr.txt' [ 0%] Checking for available updates... [----] Verifying installation... Steam Console Client (c) Valve Corporation -- type 'quit' to exit -- Loading Steam API...Failed to init SDL priority manager: SDL not found Failed to set thread priority: per-thread setup failed Failed to set thread priority: per-thread setup failed OK.
Connecting anonymously to Steam Public...Loaded client id: 7134510276319968446 Listening for IPv4 broadcast on: 27036 Logged in OK Waiting for user info...OK Downloading item 937219044 ... Success. Downloaded item 937219044 to "/home/mint/.steam/steam/steamapps/workshop/content/346110/937219044" (85577737 bytes)
I have done more testing and now a third possible directory has been found. It appears that steamcmd just does what is wants :flushed:
/home/lgsm/.steam/steam/steamapps/workshop
/home/lgsm/.steam/SteamApps/workshop
/home/lgsm/Steam/steamapps/workshop
One question? Why would you ever run the server as root or your own user? Just like Apache is run by the apache user and nginx is run by the nginx user, learn yourself some systemd, SELinux, and permissions then make yourself a steamcmd user, or name it whatever you want. House the files in the var or usr primary directories, just my two cents.
You should have your own separate user for anything that is a server so files can be guarded from rce or file tampering.
SELinux is your friend, but also your enemy, so pay attention to it for everything
The last 3 posts have nothing to go with my original issue. Not sure why it's posted here
@dgibbs64 try using the steamcmd package directly from Valve: http://media.steampowered.com/client/steamcmd_linux.tar.gz
@TTimo _have I have no reason to believe that using the steamcmd apt package causes this problem. The ubuntu apt package might be a bit old but it simply installs steamcmd using apt with no other changes. Once the package is installed on first run steamcmd will do its normal updating to the latest version.
Steamcmd seems to just decide to use one of multiple InstallPath with no obvious reason for it. I have remoted on to several LinuxGSM users game servers and results will vary with no obvious reason. Some using the steamcmd archive others using apt some using ubuntu, Debian or centOS. I just can't pin down the reason.
/home/lgsm/.steam/steam/steamapps/workshop
/home/lgsm/.steam/SteamApps/workshop
/home/lgsm/Steam/steamapps/workshop
To see the SteamCMD InstallPath you can use the info command in steamcmd. For example
Steam>info
Account:
SteamID: [U:1:0]
Email:
Logon state: Logged Off
Language: english
Persona Name:
Persona State: Offline
Direct Friends: 0
Groups Friends: 0
InstallPath: /home/arkserver/.steam/steamcmd/linux32
Universe: Public
Server Time: Tue Apr 7 14:41:46 2020
IPCountry:
Offline Mode: no
CellID: 4
steamcmd apt package contents https://packages.ubuntu.com/eoan/i386/steamcmd/filelist
Ideally, a steamcmd dev could confirm what the correct InstallPath directory should be and provide some insight into why there are several directories steamcmd might use.
Could be the XDG_* environment variables influencing it.
The ~/Steam/steamapps path is wrong, and is typically inherited/forced coming from Debian's steam package (not steamcmd, but the steam client). (semi related - see https://twitter.com/TTimo/status/1243590529625010180)
On my system it writes to ~/.local/share/Steam/logs/stderr.txt, with ~/.steam/steam being a symlink to ~/.local/share/Steam. This is the intended setup.
interesting as I don't think I have seen the use of .local before. Here is the output from me just downloading and running the official gz package in a new user. Ubuntu 18.04
root@localhost:~# su - lgsm
lgsm@localhost:~$ curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxvf -
steamcmd.sh
linux32/steamcmd
linux32/steamerrorreporter
linux32/libstdc++.so.6
linux32/crashhandler.so
lgsm@localhost:~$ ls
linux32 steamcmd.sh
lgsm@localhost:~$ ./steamcmd.sh
Redirecting stderr to '/home/lgsm/Steam/logs/stderr.txt'
ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".
[ 0%] Checking for available update...
[----] Downloading update (0 of 50,772 KB)...
[ 0%] Downloading update (2,819 of 50,772 KB)...
[ 5%] Downloading update (5,993 of 50,772 KB)...
[ 97%] Downloading update (50,497 of 50,772 KB)...
[ 99%] Downloading update (50,772 of 50,772 KB)...
[100%] Download Complete.
[----] Applying update...
[----] Extracting package...
[----] Installing update...
[----] Cleaning up...
[----] Update complete, launching...
Redirecting stderr to '/home/lgsm/Steam/logs/stderr.txt'
[ 0%] Checking for available updates...
[----] Verifying installation...
Steam Console Client (c) Valve Corporation
-- type 'quit' to exit --
Loading Steam API...Failed to init SDL priority manager: SDL not found
Failed to set thread priority: per-thread setup failed
Failed to set thread priority: per-thread setup failed
OK.
Steam>exit
lgsm@localhost:~$ ls -al
total 52
drwxr-xr-x 9 lgsm lgsm 4096 Apr 7 15:08 .
drwxr-xr-x 4 root root 4096 Apr 7 15:07 ..
-rw-r--r-- 1 lgsm lgsm 220 Apr 7 15:07 .bash_logout
-rw-r--r-- 1 lgsm lgsm 3771 Apr 7 15:07 .bashrc
drwxrwxr-x 2 lgsm lgsm 4096 Apr 7 15:08 linux32
drwxrwxr-x 2 lgsm lgsm 4096 Apr 7 15:08 linux64
drwxrwxr-x 2 lgsm lgsm 4096 Apr 7 15:08 package
-rw-r--r-- 1 lgsm lgsm 807 Apr 7 15:07 .profile
drwxrwxr-x 2 lgsm lgsm 4096 Apr 7 15:08 public
drwxrwxr-x 3 lgsm lgsm 4096 Apr 7 15:08 siteserverui
drwxrwxr-x 2 lgsm lgsm 4096 Apr 7 15:09 .steam
drwxrwxr-x 6 lgsm lgsm 4096 Apr 7 15:09 Steam
-rwxrwxr-x 1 lgsm lgsm 1166 Oct 10 2016 steamcmd.sh
The ~/Steam/steamapps path is wrong, and is typically inherited/forced coming from Debian's steam package (not steamcmd, but the steam client)
I think this is something differently wrong. The bug that Debian's steam package used to have was that it installed directly into ~/.steam, conflicting with how ~/.steam was meant to work. It seems that's also true for steamcmd, at least some of the time: the equivalent of #916303 needs fixing in Debian's steamcmd package.
Workaround: when a new user runs steamcmd, either run Steam (from Valve's official package or from a recent version of Debian's unofficial package) at least once, first; or set up the directory hierarchy that it wants, but do it correctly:
mkdir -p ~/.local/share/Steam
mkdir ~/.steam
ln -s ~/.local/share/Steam ~/.steam/root
ln -s ~/.local/share/Steam ~/.steam/steam
I am not aware of Debian's steam package having ever created ~/Steam as a Debian-specific thing.
According to a comment in Debian's steamcmd wrapper script, the steamcmd binary defaults to creating ~/Steam if you don't already have some sort of Steam installation - which is consistent with what @dgibbs64 just posted.
From the Steam client's bin_steam.sh, it looks as though old versions of Steam defaulted to the Steam installation directory being ~/Steam (CLASSICSTEAMDIR in the script), while new versions of Steam default to it being ~/.local/share/Steam (DEFAULTSTEAMDIR). Recent versions of the unofficial steam package in Debian default to ~/.steam/debian-installation, which is a bit weird but also works.
For a bit more context:
The various directories ~/Steam, ~/.local/share/Steam and ~/.steam/debian-installation (depending who you ask) are the Steam installation directory, similar to C:\Program Files\Steam on Windows. Technically this can be almost anything, as long as it isn't ~/.steam.
The ~/.steam directory is meant to be a well-known location that is separate from the Steam installation directory, and contains symbolic links that Steam components use to find the actual installation directory.
Debian bug 916303 was that Debian's steam package defaulted to using ~/.steam as the Steam installation directory in addition to its intended purpose, which caused various files to collide. This has since been fixed. However, Debian's steamcmd package has a similar bug (workaround above).
thanks @smcv really useful information here to give me a better understanding of SteamCMD. I will use this to investigate further. I did "fix" the problem by LinuxGSM searching for the Ark appworkshop_346110.acf file and using that to symlink to the workshop dir https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/fix_ark.sh#L10
In an ideal world, it would be useful for the official archive, apt and an rpm to work in the same manner with the same directories. Making it easier to install steamcmd across deb and red-hat distros.
In an ideal world, it would be useful for the official archive, apt and an rpm to work in the same manner with the same directories.
Valve does not directly control the packages that are available in Debian, Ubuntu or any other distribution, but I've opened a downstream Debian bug for this: #956122.
At some point there will hopefully be an official writeup of how ~/.steam relates to the Steam installation directory, which distros can use to check that they're getting it right.
From what you pasted above, it looks as though by default, the official steamcmd archive is consistent with older versions of the Steam client, which defaulted to ~/Steam instead of ~/.local/share/Steam for the installation directory. An updated steamcmd archive would probably help to clarify this; so would more documentation.
This is brilliant @smcv Thank you 🙌 .
Its a shame that Valve does not control these packages as it would help with consistency across distros.
Would this sort of fix be passed on to Ubuntu repos as well? (sorry no experience in this area) as it would go a long way to add consistency.
Would this sort of fix be passed on to Ubuntu repos as well?
Fixes in Debian eventually get into Ubuntu, but that progression is up to Ubuntu developers. I'm involved in Debian but not Ubuntu, so I have no control over what Ubuntu pick up from us or when they do it.
Failed to set thread priority: per-thread setup failed
@dgibbs64 is that error message something I can live with on Ubuntu 18.04?
Failed to set thread priority: per-thread setup failed
I don't think that message has anything to do with whether steamcmd is dealing with ~/.local/share/Steam, ~/Steam or ~/.steam.
Is it possible I'm getting bit by something related to this in 2025? I'm using steamcmd to verify/update a game client, not a server (don't ask.) It was working fine yesterday, but today I'm running into a strange problem...
I use ~/Steam as my steam library (I want my files easily accessible, not in some oddball hidden directory), and I was running into a strange issue: when I used steamcmd to update this game, as such:
force_install_dir "/home/merc/Steam/steamapps/common/Gray Zone Warfare"
login [user] [pass]
app_update 2479810
quit
my Steam client just stops seeing my added library at ~/Steam. It's removed, and Steam thinks I have no games installed. If I add ~/Steam back in steam GUI, it sees the games (and re-downloads shader cache.)
I was also seeing it knock my Steam client offline, which it definitely wasn't doing for some reason yesterday. I see in the Steamcmd support page at Valve:
Note: A user can only be logged in once at any time (counting both grapical client as well as SteamCMD logins).
Which, ok, fine, but I'm SURE it wasn't knocking my Steam client off yesterday. And while I was googling around, I come across the fact that Debian is doing something about ~/Steam, and I find this issue...
I am using steamcmd straight from Steam (https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz) but... is it possible steamcmd wants to do internal stuff in ~/Steam (unrelated to updating a game), and is doing weird stuff cuz I have an actual steam library in ~/Steam?
