Steam disk-free check on automounted shares cause huge delay on startup.

[sankasan]

Your system information

• Steam client version (build number or date): Aug 20 2021, at 20:39:31
• Distribution (e.g. Ubuntu): Arch
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

For whatever reason, it seems that at times Steam wants to check my disk space. It might be related to an unclear closing but not sure. Anyways, what happens is that it tries to go over all shares as defined in /etc/fstab. In my particular case I have a few automount shares which only work when connected to Work VPN. However Steam tries to access them (which in itself is already not so cool) but as a side effect locks the SteamUI for a couple of minutes.

Below a snippet of what I see in the log for each of these shares.

src/tier1/fileio.cpp (3867) : Assertion Failed: statvfs64 failed for /data/Work/Network/General, errno 112
src/tier1/fileio.cpp (3867) : Assertion Failed: statvfs64 failed for /data/Work/Network/General, errno 112
Execute: /home/san/.local/share/Steam/ubuntu12_64/disk-free /data/Work/Network/General >/tmp/disk-free.vmWPQ3
statvfs64 /data/Work/Network/General: ret -1 errno 112
  f_bsize : 0
  f_frsize: 0
  f_blocks: 0
  f_bfree : 0
  f_bavail: 0
src/tier1/fileio.cpp (3897) : Assertion Failed: disk-free command failed

src/tier1/fileio.cpp (3897) : Assertion Failed: disk-free command failed

statvfs64: ret -1 errno 112
  f_bsize : 0
  f_frsize: 0
  f_blocks: 0
  f_bfree : 0
  f_bavail: 0
src/tier1/fileio.cpp (3867) : Assertion Failed: statvfs64 failed for /data/Work/Network/Projects, errno 112
src/tier1/fileio.cpp (3867) : Assertion Failed: statvfs64 failed for /data/Work/Network/Projects, errno 112
Execute: /home/san/.local/share/Steam/ubuntu12_64/disk-free /data/Work/Network/Projects >/tmp/disk-free.Twi61K
statvfs64 /data/Work/Network/Projects: ret -1 errno 112
  f_bsize : 0
  f_frsize: 0
  f_blocks: 0
  f_bfree : 0
  f_bavail: 0
src/tier1/fileio.cpp (3897) : Assertion Failed: disk-free command failed

src/tier1/fileio.cpp (3897) : Assertion Failed: disk-free command failed

Steps for reproducing this issue:

1. Setup automounted shares via systemd in /etc/fstab such as:

   /SomeNetworkShareServer/SecretProjects          /data/Work/Network/Projects     cifs    noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev,rw,uid=1000,gid=1000,workgroup=MySecretWorkgroup.local,credentials=/etc/secrets/credentials.txt

2. Launch Steam without VPN connected (thus share won't work)
3. Behold a non responsive UI and lots of spam as shared above in the terminal.

[Plagman]

Probably only need to check disk space on filesystems where there's libraries.

[TTimo]

Hello @sankasan - do you have a line with that share in /proc/mounts? This is where the Steam client would be finding it. What does the line look like, same as your fstab entry?

[sankasan]

Hello @sankasan - do you have a line with that share in /proc/mounts? This is where the Steam client would be finding it. What does the line look like, same as your fstab entry?

Hi @TTimo. Yeah I can help you with that. The format of both files are a bit different.

This is how a share looks in /etc/fstab:

//ServerName/general        /data/Work/Network/General      cifs    noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev,rw,uid=1000,gid=1000,workgroup=DomainName.local,credentials=/some/secret/path/credentials-file.txt,vers=3.0   0 0

And this is how it is represented in in /proc/mounts:

//ServerName/general /data/Work/Network/General cifs rw,relatime,vers=3.0,cache=strict,username=MyDomainUsername,domain=DomainName.local,uid=1000,noforceuid,gid=1000,noforcegid,addr=172.16.0.111,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1 0 0

Hope this helps. Let me know if I can provide any additional information.

[EDIT] Updated to reflect the exact same example of my VPN share.

[bradsk88]

Seeing the same problem on archlinux during game installs - except rather than failing due to network availability, it's simply trying to write to mounted paths that the user doesn't have access to (e.g. /).

Is there any sort of workaround available?

[bradsk88]

Logging in as another user who has elevated privileges.

[nPHYN1T3]

Started seeing this tonight where Steam tries to write .steam_exec_test.sh to every GD place it can. Once again showing why I don't trust Steam when it's trying to write random scripts to my boot partitions etc. Who the hell at Valve thought it was a good idea to try to write random crap to /boot/efi or /root!? Probably the same #$% that came up with how Steam privilege escalates over root right?

God I wish I could take my games and leave this platform! If only the games I bought 20+ years ago came with a warning of how evil this would become...

[sipaktli]

Logging in as another user who has elevated privileges.

Just no. that's insane. Why would steam be given write permissions on all drives and even worse, to be run as a privileged user? No no and no. Huge security hole right there. Steam should not be scanning anything outside the running user at all. If the user so does chose to go and manually add a path and the user has permissions, (as it used to), then all good.

This is a bug.

[nPHYN1T3]

This is a bug.

No...it's a feature! (for Valve and partnered hardware vendors as they annihilate your write cycles and abuse spin-up time!)

And yes Steam can undo/change permissions set by root while running as an unprivileged user.

[sipaktli]

Reason why I've always ran it chrooted. It's still getting mountpoints via 'mounts' or something. Shady af indeed.

[nPHYN1T3]

Yeah I run it in a separate namespace these days for control over the nefarious things it does. Sadly jailed or not it's beyond broken anymore. It doesn't run how I normally run it at all anymore (breaks with overyfs these days too) and it's so garbage and sketch it's become like a modern day Bonzai Buddy. cough my.steamchina.com cough community.csgo.com.cn