Error: Steam "needs at least 250MB" free space when plenty of space
apiontek opened this issue · 98 comments
Your system information
- Steam client version (build number or date): 1:1.0.0.54+repack-2ubuntu5
- Distribution (e.g. Ubuntu): Ubuntu Gnome 17.04
- Opted into Steam client beta?: [Yes/No] Yes but fresh install
- Have you checked for system updates?: [Yes/No] Yes
Please describe your issue in as much detail as possible:
Running Steam for the first time on fresh install, system fully updated. My homedirs are ZFS datasets. This has worked in the past, on an Ubuntu 16.04 system, same ZFS homedir setup, but that may have been over 6-10 months ago, last time I used it.
In current environment, running steam I get error window "Steam - Fatal Error" "Fatal Error: Steam needs at least 250MB of free disk space to update." Running from terminal produces output (gist)
df -h output (gist) -- every partition available has plenty of space.
apt-cache policy steam output (gist)
i also see in the terminal output, "Steam needs to be online to update" -- I have an active network connection. It is non-standard, being a bridge on top of a bonded interface, but this also worked in the past.
Steps for reproducing this issue:
- install Ubuntu Gnome 17.04, ensure up-to-date
- have a ZFS dataset, with e.g. tank/homes mounted to /home -- and in my case, tank/homes/userX as separate datasets mounted to /home/userX
- try to run steam for the first time
Hello @apiontek, as a test, can you remove both the distro and valve variants of the steam package, then move ~/.steam and if it is there, ~/.local/share/Steam somewhere out of the way. Then add either the distro-provided or valve-provided steam package, but not both and re-run steam.
I had already done that. I originally had distro-provided steam package installed. I removed ~/.steam and ~/.local/share/Steam, then did a find ~/ -iname "steam" and removed ~/.steampid, ~/.steampath, and ~/Steam I think. I then purged the distro-provided steam, downloaded steam-latest.deb, and installed that. Upon getting the same error, I submitted this issue.
Just now however, I tried again, running sudo apt purge steam-launcher after a dpkg -l | grep -i steam and removing ~/.steam and ~/.local/share/Steam again.
This time I reinstalled the distro-provided package and had the same result.
Tried again and reinstalled the valve-provided package, and have the same result. I get the error with both.
Thanks for the confirmation @apiontek.
As an update, since my root system is on ext4, I created a temporary /opt/steam folder with subfolders for .steam, local-share-Steam, and Steam, and did ln -s for each of them into the appropriate places in my homedir.
Then, the steam installer worked fine. But when I remove the symlinks and move the folders into position, although Steam starts up fine, I can't install games because it reports 0 space free.
So it seems I could run games with folders symlinked to an ext4 partition, but this isn't optimal for me. My root partition is a small SSD. I wonder if I can create a ZFS block device formatted ext4, and symlink again? I'll try that.
Editing to add: creating an ext4-formatted zvol and symlinking the steam folders to folders on that volume, does work and allow me to install & run games. Not ideal, but I can run games for now!
Same problem on Arch Linux when trying to add new Steam Library folder located on ZFS volume: Steam shows 0 bytes free space in such folders.
Got same problem on gentoo
STEAM_DEBUG=1
DEBUGGER=strace
steam_debug.txt
steam.strace.txt
Same problem on Xubuntu 17.04
Chiming in, Gentoo user here.
- I can run some games, but not install any new ones.
- Steam reports 0MB free for my ZFS partition, but enough for my homedir.
cinu cybik # uname -a; equery list zfs zfs-kmod spl
Linux cinu 4.12.1-gentoo-cybik #1 SMP Sat Jul 15 00:10:04 PDT 2017 x86_64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux
* Searching for zfs ...
[IP-] [ ] sys-fs/zfs-0.6.5.11:0
* Searching for zfs-kmod ...
[IP-] [ ] sys-fs/zfs-kmod-0.6.5.11:0
* Searching for spl ...
[IP-] [ ] sys-kernel/spl-0.6.5.11:0
My specific console error:
../tier1/fileio.cpp (3264) : Assertion Failed: Failed to determine free disk space for /media/Games/cybik/Steam, error 75
../tier1/fileio.cpp (3264) : Assertion Failed: Failed to determine free disk space for /media/Games/cybik/Steam, error 75
../tier1/fileio.cpp (3264) : Assertion Failed: Failed to determine free disk space for /media/Games/cybik/Steam, error 75
GameAction[AppID 2820, ActionID 1] : RunGame failed with NotInstalled with ""
../tier1/fileio.cpp (3264) : Assertion Failed: Failed to determine free disk space for /media/Games/cybik/Steam, error 75
../tier1/fileio.cpp (3264) : Assertion Failed: Failed to determine free disk space for /media/Games/cybik/Steam, error 75
../tier1/fileio.cpp (3264) : Assertion Failed: Failed to determine free disk space for /media/Games/cybik/Steam, error 75
@kisak-valve when will this be fixed (or at least an option that allows you to skip checking free space)? It's a bit(very) annoying that i cannot use steam.
Same problem with steam and gog installers under wine, maybe we need to report a bug to zfs.
I'm starting to think we should bring in the zfs driver developers.
I'm having the same issue with Steam on Arch. I'm using btrfs instead of zfs though, but trying to install Steam games to another drive mounted at /storage. Steam claims there are 0 bytes of disk space free, which isn't true. I've confirmed that reading and writing to the drive works.
Seems valve fixed this in beta update. UPD: Seems something updated in system, because the Steam and GOG installers in Wine are now correctly show the free space.
Thanks for testing @soredake, is anyone else having this issue with zfs or btrfs with the steam beta client? If needed, you should be able to manually opt-in to the steam beta with touch ~/.steam/steam/package/beta.
Steam package versions 1503954609, still can't install (reporting 0MB free).
Using zfs, Steam Linux Native.
Still happening on steam beta with package version 1503954609 on Manjaro 17.0.2 and ZFS v0.6.5.9-2
My free space is correct now and I am able to install games to libraries in my zfs datasets. This is on Fedora 26.
Name : zfs
Version : 0.7.1
Release : 1.fc26
Arch : x86_64
Size : 1.0 M
Source : zfs-0.7.1-1.fc26.src.rpm
@nathandorsey gave me the idea of updating my zfs (0.6.x to 0.7.1), but I still have 0mb available.
cinu cybik # uname -a; echo ============; equery l zfs zfs-kmod spl;
Linux cinu 4.12.1-gentoo-cybik #2 SMP Sat Jul 15 14:55:14 PDT 2017 x86_64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux
============
* Searching for zfs ...
[IP-] [ ] sys-fs/zfs-0.7.1:0
* Searching for zfs-kmod ...
[IP-] [ ] sys-fs/zfs-kmod-0.7.1:0
* Searching for spl ...
[IP-] [ ] sys-kernel/spl-0.7.1:0
@cybik i'm on 0.7.1 zfs, 4.12.8 kernel and 6.4.0 gcc, maybe this will help you.
Additionaly:
Kernel config https://notabug.org/soredake/dotfiles_home/src/master/kernel/.config_4_12_8
Portage settings: https://notabug.org/soredake/dotfiles_home/src/master/etc/portage/portage
Kernel updated, still an issue.
Config Snapshot: https://github.com/cybik/currentconfigs (not for the faint of heart)
Steam Version: 1503954609
cinu cybik # uname -a; echo ============; equery l zfs zfs-kmod spl;
Linux cinu 4.12.8-gentoo-cybik #1 SMP Sat Sep 2 09:20:51 PDT 2017 x86_64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux
============
* Searching for zfs ...
[IP-] [ ] sys-fs/zfs-0.7.1:0
* Searching for zfs-kmod ...
[IP-] [ ] sys-fs/zfs-kmod-0.7.1:0
* Searching for spl ...
[IP-] [ ] sys-kernel/spl-0.7.1:0
@cybik nothing interesting
* Searching for zfs ...
[IP-] [ ] sys-fs/zfs-0.7.1:0
* Searching for zfs-kmod ...
[IP-] [ ] sys-fs/zfs-kmod-0.7.1:0
* Searching for spl ...
[IP-] [ ] sys-kernel/spl-0.7.1:0
And my zpool options ashift=12 -o compression=lz4,checksum=edonr,dnodesize=auto,xattr=sa
Just wanted to see if you had any -r1 or anything of the sort.
I just cleared my Steam executable tree in .local, I still don't have anything functional. Zfs 0.7.1 all around
Could it be that some libraries installed on my system are clashing with what Steam is expecting?
Seeing the same issue in the backup/restore dialog as well. Ubuntu 17.04 and ZFS version 0.6.5.9-2
Seeing this on Arch:
Name : zfs-linux
Version : 0.7.1.4.12.13.1-1
Description : Kernel modules for the Zettabyte File System.
Architecture : x86_64
URL : http://zfsonlinux.org/
Name : linux
Version : 4.12.13-1
Description : The Linux kernel and modules
Architecture : x86_64
URL : https://www.kernel.org/
Steam package versions: 1504757234
Steam build date: Sep 6 2017
Just encountered this on Arch right after starting steam [official repo] with Kernel 4.13.3 and corresponding ZoL 0.7.2 [.4.13.3.1-1].
CLI error states:
Assert( Assertion Failed: Failed to determine free disk space for ., error 75 ):../tier1/fileio.cpp:3186
As a further note I zfs mount a seperate zpool/user to /home/user (very common practice).
Workaround for now: As ZFS distributes space evenly among any dataset and steam is unable to understand this yet, you can set ZFS attribute quota on your dataset that's mounted to /home. Please read the zfs manuals if you don't know what this attribute does or how to use it.
Confirming, setting a quota works, even outside of a mounted-in-home dir. I set a quota to 1500G and it started working without Steam even restarting.
This can help Valve find out why the balls this is being read wrong.
Further to above, if I set a quota greater than 4T disk space is not determined correctly. 4T or less works fine.
Hello @aots-aots, please open a separate issue report for the 4TB quota issue so that it can be tracked properly.
I set my quota to 4T for the zfs pool mounted at ~/tank, yet steam still doesn't get the size. This is annoying, it basically makes steam useless for my needs
This also effects me, running Ubuntu 17.04.
About a year ago on Ubuntu 16 steam did detect the available free space and the games installed and ran from the zfs filesystem.
I have the same problem. Here my setup (Fedora 27):
[richi@wlx001 ~]$ uname -r
4.14.8-300.fc27.x86_64
zfs:
Name : zfs
Version : 0.7.5
Release : 1.fc27
Arch : x86_64
Size : 1.0 M
Source : zfs-0.7.5-1.fc27.src.rpm
Repo : @System
From repo : zfs
Summary : Commands to control the kernel modules and libraries
URL : http://zfsonlinux.org/
License : CDDL
Description : This package contains the ZFS command line utilities.
steam:
Name : steam
Version : 1.0.0.54
Release : 13.fc27
Arch : i686
Size : 2.7 M
Source : steam-1.0.0.54-13.fc27.src.rpm
Repo : @System
From repo : rpmfusion-nonfree-updates
Summary : Installer for the Steam software distribution service
URL : http://www.steampowered.com/
License : Steam License Agreement
Description : Installer for the Steam software distribution service.
: Steam is a software distribution service with an online store, automated
: installation, automatic updates, achievements, SteamCloud synchronized savegame
: and screenshot functionality, and many social features.
My home is on a ZFS pool:
Filesystem Size Used Avail Use% Mounted on
data/home 5.3T 24G 5.3T 1% /home
This is a fresh setup, so i can't even install steam. The touch ~/.steam/steam/package/beta trick also didn't work. Might it be the i686 arch for the steam package?
Edit:
Setting a quota worked.
This looks like a duplicate of #4824.
I have the same problem. I have my home dirs on a zfs pool, and my home dir is a seperate dataset. I am running Ubuntu 17.10 amd64 and installed steam-installer from the multiverse repo.
ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".
[2018-01-02 14:59:29] Startup - updater built Nov 23 2016 01:05:42
ILocalize::AddFile() failed to load file "public/steambootstrapper_greek.txt".
[2018-01-02 14:59:29] Verifying installation...
[2018-01-02 14:59:29] Unable to read and verify install manifest /home/dimitris/.steam/package/steam_client_ubuntu12.installed
[2018-01-02 14:59:29] Verification complete
[2018-01-02 14:59:29] Downloading Update...
../tier1/fileio.cpp (3186) : Assertion Failed: Failed to determine free disk space for ., error 75
[2018-01-02 14:59:29] Error: Steam needs at least 250MB of free disk space to update.
[2018-01-02 14:59:29] Error: Steam needs to be online to update. Please confirm your network connection and try again.
[2018-01-02 14:59:34] Shutdown
nfs mount as of 2 client updates ago the steam system cant figure out space on the mounts. I have reinstalled os and same issue. im using ubuntu 16.04 lts
Curious thread.. @kermeat I don't run Gentoo but this seems rather odd no? What is in /etc/os-release?
+++ BUG_REPORT_URL=https://bugs.gentoo.org/
Steam/steam.sh: line 154: VERSION_ID: unbound variable
+ kermeat 0
How steam got to here is more concerning:
+ mkdir -p /home/kermeat/.local/share/Steam/.save
Steam/steam.sh: line 444: no match: ssfn*
+ '[' 133 -eq 42 ']'
The error itself is expected from bash because steam sets failglob but the bootstrap failed, it shouldn't have tried to backup those files, they could be corrupt.
Like a lot of bugs open atm, I don't understand how Valve isn't able to address this? You literally have at least two reports showing exactly what is wrong and nothing end users can do about it.
h1z1,
Gentoo, being of the rolling release sort, doesn't have versions, so the (optional) variable here is indeed unset:
NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo/Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.gentoo.org/"
SUPPORT_URL="https://www.gentoo.org/support/"
BUG_REPORT_URL="https://bugs.gentoo.org/"
Stupid work around for those who need it until steam fixes this issue. get a drive with 40+gb space [ie atleast as large as your larges install.] make a dir for the library on it and add it as a library. close steam and rm the steam apps folder on that drive with space. use ln -s [nfs mount location] steamapps when you open steam it will show that folder with how ever much space is currently free on your local dummy drive. as long as you know you have plenty of space on the file share you can install/play to your hearts content...
I set a quota of 3TB and while Steam runs, if I try to install a game it tells me I don't have enough space.
# zfs list tank/homes/adam
NAME USED AVAIL REFER MOUNTPOINT
tank/homes/adam 784G 2.23T 229G /home/adam
# zfs get quota tank/homes/adam
NAME PROPERTY VALUE SOURCE
tank/homes/adam quota 3T local
If I instead create a zvol, format it ext4, move the steam directories to it and symlink those back to my home directory, then games install and run. I'm currently on Ubuntu 17.10 with zfs release 0.6.5.11-1ubuntu3.1, with Steam client on beta updates. About says package version 1508957438, built Oct 25 2017 at 00:42:26, dpkg says version 1:1.0.0.54+repack-2ubuntu5
EDIT:
I realized that seemed old, and I hadn't run Steam in a while, so I waited and got an update, bringing me up to package version 1521764535, built Mar 22 2018 at 16:58:48 ... but I have the same problem. Despite a quota of 3T being set on my /home/user zfs volume, Steam complains when trying to install a game that there isn't enough space for it. There's plenty. Still works if I move the steam directories to an ext4-formatted zvol.
Setting the quota to 2T worked for me. Anything higher and it fails.
Just to chime in I get the same behavior as #4982 (comment) on:
$ modinfo zfs | head
filename: /lib/modules/4.15.15-1-ARCH/extra/zfs/zfs.ko.xz
version: 0.7.0-415_g74df0c5e2
license: CDDL
author: OpenZFS on Linux
description: ZFS
alias: devname:zfs
alias: char-major-10-249
srcversion: C56510077A308A2571DBAD4
depends: spl,znvpair,icp,zlua,zunicode,zcommon,zavl
retpoline: Y
# zfs get quota datavol/games
NAME PROPERTY VALUE SOURCE
datavol/games quota none default
# zfs set quota=2T datavol/games
# zfs get quota datavol/games
NAME PROPERTY VALUE SOURCE
datavol/games quota 2T local
# zfs list datavol/games
NAME USED AVAIL REFER MOUNTPOINT
datavol/games 1.02T 1005G 683G /mnt/datavol/games
Now I can install games again.
The quota workaround is working.
I can set it to 2262G, not higher. But still, it's a workaround and I'd like to keep my whole datapool without quota.
Just chiming in as I've hit this problem too today. The quota tactic has also worked for me while installing a CSGO server in it's own zfs dataset.
#ZFS on Linux - version: 0.7.6-1.el7_4
#Dist and Kernel: CentOS7 - 3.10.0-693.2.2.el7.x86_64
zfs create storage/csgoserver-retakes
zfs set quota=30G storage/csgoserver-retakes #csgo takes about 15G on it's own
#Then executing further steamCMD install commands, works fine.
It's a shame steamcmd can't just see the total pool size and say "Ok that's our max". I imagine it's calculating against what ZFS has 'allocated' (that small cushion of Mb) to a volume rather than the pool's overall max storage space.
Setting this 'quota cap' must give steamcmd the answer's it's looking for, an actual, hard defined, max size. I guess I'll just have to expand that allocation manually if the content/game-updates get too large. But this does seem like a discovery and calculation problem for steamcmd , not anything ZFS's 'fault' but rather an incompatibility.
Yes. I'd much rather steam adapt to handle ZFS. It's bad enough to be forced to set a quota, but to also have it not work if the quota is over 2TB is baffling.
That said, yes, once I set a home quota to 2TB, it worked. Then to allow more space, I made my ~/.steam dir its own ZFS volume and set that quota to 2TB, since my home dir is often pretty full.
Considering it's not entirely strange any more to have 1) 2TB or more of space and 2) A steam library to fill that space. There are MANY threads about this going back to at least 2014ish.
Really quite baffling indeed. Then again we're talking about Valve.
ZFS 0.7.7 on Proxmox. Strange thing. Issue look like depending on phy device. On HDD with ZFS i have 0 bytes to write. On the ZFS SSD Raid everything is working fine. The datasets have the same settings.
Server: Proxmox with ZFS 0.7.7
Client KDE-Neon
In my experience it is not fully depending on the Server. It is depending on the Client. So what does it do?
Client Kernel 4.13 and Kernel 4.15:
- ZFS Dateset (HDDraid) mounted on Client via NFS, 0 bytes free
- ZFS Dataset (HDDraid) mounted on Client via CIFS v1.0 and v3.0, 0 bytes free
- ZFS Dataset (SSDraid) mounted on Client via NFS/CIFS everyting is working fine
Client Kernel 4.4:
- ZFS Dateset (HDDraid) mounted on Client via NFS, everyting is working fine
- ZFS Dataset (HDDraid) mounted on Client via CIFS v1.0 and v3.0, everyting is working fine
- ZFS Dataset (SSDraid) mounted on Client via NFS/CIFS everyting is working fine
Windows10 as Client, ZFS Dataset mounted via CIFS also everything is working fine.
Steamclient directly on the Server didn't work with Kernel 4.15, not tested with older Kernels.
i have a ext4 (so no way to set a quota) FS on a ~3TB lvm cachepool (consisting of 120gb ssd + 3 partitions on 3tb ssd because of mbr table not supporting a huge partition, details see below) on 4.14, and it has the same issue:
Steam (beta channel, updated today) reports 0 bytes free when trying to install a game, but 600GB free when in the library paths window (both values wrong, but the 600 could still be explained by different calculations/etc, at least it's closer to the 578 df shows, see below).
it doesn't show up the ../tier1/fileio.cpp (3186) : Assertion Failed: Failed to determine free disk space for ., error 75 line though and strace doesn't contain any EOVERFLOW values.
$ uname -a
Linux t1.nonchip.de 4.14.30_1 #1 SMP PREEMPT Wed Mar 28 07:51:56 UTC 2018 x86_64 GNU/Linux
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_pool-lv_root 2.7T 2.0T 578G 78% /
$ parted -l
Model: ATA KINGSTON SA400S3 (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 120GB 120GB lvm
Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 32.3kB 2149MB 2148MB primary ext4 boot
4 2149MB 16.8GB 14.6GB primary lvm
2 16.8GB 1509GB 1492GB primary lvm
3 1509GB 3001GB 1492GB primary lvm
$ lvdisplay; vgdisplay; pvdisplay
--- Logical volume ---
LV Path /dev/vg_pool/lv_root
LV Name lv_root
VG Name vg_pool
LV UUID 9Y1Hk6-EE2Z-Yokl-f62E-u0lD-YkhN-mIdJbM
LV Write Access read/write
LV Creation host, time t1.nonchip.de, 2018-05-06 12:40:12 +0200
LV Cache pool name lv_cache
LV Cache origin name lv_root_corig
LV Status available
# open 1
LV Size <2.73 TiB
Cache used blocks 46.53%
Cache metadata blocks 1.02%
Cache dirty blocks 0.00%
Cache read hits/misses 5474240 / 897199
Cache wrt hits/misses 12561672 / 515697
Cache demotions 0
Cache promotions 232807
Current LE 714883
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:3
--- Volume group ---
VG Name vg_pool
System ID
Format lvm2
Metadata Areas 4
Metadata Sequence No 17
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 4
Act PV 4
VG Size <2.84 TiB
PE Size 4.00 MiB
Total PE 743500
Alloc PE / Size 743043 / 2.83 TiB
Free PE / Size 457 / <1.79 GiB
VG UUID Z65NUl-ky7i-uEji-KGNm-p14m-LLyW-6rqCxZ
--- Physical volume ---
PV Name /dev/sdb2
VG Name vg_pool
PV Size <1.36 TiB / not usable 1.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 355698
Free PE 0
Allocated PE 355698
PV UUID ewUXfj-Y3DB-Ne3h-rfI6-ZgYs-O8A8-KDM9s3
--- Physical volume ---
PV Name /dev/sdb3
VG Name vg_pool
PV Size <1.36 TiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 355697
Free PE 0
Allocated PE 355697
PV UUID 8pDh35-sFMk-x4Il-ezRu-75PT-8R4x-h08h95
--- Physical volume ---
PV Name /dev/sdb4
VG Name vg_pool
PV Size <13.63 GiB / not usable 2.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 3488
Free PE 0
Allocated PE 3488
PV UUID uDfXA1-jA2t-R0eX-AD62-eaVc-EbLg-C8nYsj
--- Physical volume ---
PV Name /dev/sda1
VG Name vg_pool
PV Size <111.79 GiB / not usable 4.44 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 28617
Free PE 457
Allocated PE 28160
PV UUID 8RY1Yk-DnSk-UWF0-eobx-NKbJ-xqow-21ueL3
just tried making a LD_PRELOADable library to wrap [f]stat[v]fs[64], that seems to be called by steam a lot, but doesn't influence the numbers shown in the install dialog or library paths window, which is a bit confusing to me, because as far as i know those functions should be the only way to get fs space information. if anyone is able to figure out which function is actually used by steam i'd be glad to implement a wrapper for it and share it here, to get at least a temporary workaround until valve fixes this issue.
EDIT: my work so far is over at https://github.com/nonchip/steam_workaround_fsoverflow, if anyone can help me figure out how to get it to actually work it'd be much appreciated, also the informations we could collect using that might help valve fix the underlying issue.
I'm running into this same problem except with NFS.
My Steam games are on a partition mounted via NFS (over a 10GbE link) with 5.9T free and I get a fatal error that I need at least 250MB free and can't start the app.
This used to work fine as of only a few days ago.
I have the same problem here with Fedora 28 and ZFS.
When I strace the steam executable, it's failing on this syscall:
write(1, "[2018-05-25 23:13:16] Downloadin"..., 44) = 44
write(5, "[2018-05-25 23:13:16] Downloadin"..., 45) = 45
getcwd("/nfs/play/steam-games", 16384) = 26
access(".", F_OK) = 0
statfs64(".", 84, 0xf147b8b8) = -1 EOVERFLOW (Value too large for defined data type)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gettid() = 304
write(1, "../tier1/fileio.cpp (3186) : Ass"..., 99) = 99
getpid() = 302
access("/proc/302/status", F_OK) = 0
openat(AT_FDCWD, "/proc/302/status", O_RDONLY) = 10
fstat64(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
_llseek(10, 0, [0], SEEK_SET) = 0
read(10, "Name:\tsteam\nUmask:\t0002\nState:\tS"..., 1024) = 1024
gettid() = 304
_llseek(10, 1024, [1024], SEEK_SET) = 0
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
+++ killed by SIGTRAP (core dumped) +++
The Steam binary needs to be rebuilt with a -D_FILE_OFFSET_BITS=64 compiler define so that glibc will use the right version of the statfs structure that's actually large enough to hold some of the values that the kernel is trying to return.
Just like @wrffrz, I also have my home directory built on an NFS mount point, and the strace I ran looked very similar.
However, I found that I could work around the issue by turning ~/.local/share/Steam into a symlink that pointed to a non-NFS filesystem (in my case xfs). Once I did that I was able to update and run Steam just fine.
~/.local/share/Steam
Haven't this path here on Ubuntu's. There is only a ~/.steam. I moved it to /bla and it is working. But storageplace on nonssd-ZFS are still on 0byte free.
I've connected my steamlib with cifs. It works perfectly.
As long as direct mount with ZFS didn't work, this is my workaround that i can use ZFS with steam.
@boospy doesn't fix the problem though. e.g. for some people (including me) it fails because of an integer overflow when the hard drive is just too big for the 31bit substraction they do. the only thing your samba hack fixes is the kernel incompatibility they introduced on top of it.
Can we have an environment variable to skip the space check?
@megatog615 since valve doesn't care for a few years now, that's precisely what i'm trying to achieve over at: https://gitlab.com/nonchip/steam_workaround_fsoverflow but can't get it to work :P
if you have any ideas just tell me :D
@nonchip See my implementation of a workaround on a related issue. Steam uses statvfs64, a fact that can be discovered by disassembling the Steam binary in ~/.steam/bin/steam. Your preload module wraps most syscalls, but seems to be missing that one which is why it doesn't work.
@tchebb thanks much, that seems to help. can't verify it 100% since either valve or the kernel seem to have fixed the issue on my machine, but it does seem like it at least influences the readings. i'll see if i can implement it into a useful tool for anyone who still experiences this problem
edit: actually it looks like your code is already perfectly fine as said tool, so i guess i'll just point people your way instead :3
Has any more progress been made on this? This appears to be a very wide-spread issue for ZFS users.
Now that you guys have Proton out and seem to have a good number of resources for Steam on Linux, it would be great to get this finally fixed once and for all.
At least just comment out the offending code temporarily as a work-around... This is a big usability issue for Steam on Linux. Like I have moderately good Linux skills and I can't think of a work-around for this. Someone new to Linux? Forget about it, they won't be able to work around this.
CC: @kisak-valve
This still happens to ubuntu 18.04 zfs user (me) :)
setting quota works :)
zfs set quota=2T rpool/home
This is affecting me too. I can't use the quota trick since my dataset is over 2TB in size. I just bought a number of Steam games before upgrading to ZFS, too.
Please fix this. It also fails when Steam is run through Wine.
Steam is totally unusable for me until this is fixed.
I am the Gentoo ZFS maintainer. Someone just reported this to me. If it helps, you can make a dataset at ${HOME}/.local/share/Steam and then set a quota on that. It is the best that can be done until Valve fixes this. It is definitely a bug in their client.
To add some analysis, I find the 2TB free space limit to be strange. In particular, the storage space is represented in units of logical sectors, which are defined in ->f_bsize. If ->f_bsize were the traditional 512 byte size, then 2TB would be the limit of 32-bit signed integers, which is consistent with observations. However, ->f_bsize on ZFS is the recordsize, which is 128KB. The kernel should not return EOVERFLOW on 32-bit until 512TB at the default recordsize if my read of put_compat_statfs64 is correct:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/statfs.c#n304
Also, @nonchip said that he did not see EOVERFLOW on ext4 with a 3TB volume while @wrffrz did see it. The only way this makes sense to me is that @wrffrz has a combination of an inordinate amount of free space or a small recordsize. ../tier1/fileio.cpp (3264) : Assertion Failed: Failed to determine free disk space for /media/Games/cybik/Steam, error 75 makes more sense to me.
In short, Valve's programmers did not handle large filesystems properly. My guess is that they convert the block size into 512-byte logical sectors and they assume that a 32-bit signed integer can always handle it. This suggests to me that the Steam client might be happy with 5TB of free space due to how integer wraparound works. If true, Valve's developers could have tested against larger storage sizes and not have seen the issue because integer wraparound just so happened to suppress the issue.
It is likely possible to workaround this with a LD_PRELOAD shim that will set the values to something that the Steam client understands. It would probably involve truncating free space (and possibly also used space), but I imagine that it would have a good chance of working. If the Steam client relies on used space for its own internal accounting, it could mess that up (and possibly trigger a different assertion if the programmers had the foresight to create one).
Anyway, that is all that I have to say on this.
I've got 11T free in a 14T zfs dataset mounted via nfs3 over a 10GbE link--
$ ls -l ~/.steam
lrwxrwxrwx 1 jesse jesse 25 Jul 5 02:20 /home/jesse/.steam -> /archive/play/steam-games
$ df -h ~/.steam
Filesystem Size Used Avail Use% Mounted on
nas:/mnt/y/archive 14T 3.3T 11T 25% /archive
$ mount | grep /archive
nas:/mnt/y/archive on /archive type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.8,mountvers=3,mountport=758,mountproto=udp,local_lock=none,addr=192.168.1.8)
$ steam
[2018-09-19 16:40:22] Startup - updater built Nov 23 2016 01:05:42
Looks like steam didn't shutdown cleanly, scheduling immediate update check
[2018-09-19 16:40:22] Checking for update on startup
../tier1/fileio.cpp (3186) : Assertion Failed: Failed to determine free disk space for ., error 75
[2018-09-19 16:40:22] Error: Steam needs 250MB of free disk space to update.
[2018-09-19 16:40:22] Verifying installation...
[2018-09-19 16:40:22] Performing checksum verification of executable files
[2018-09-19 16:40:22] Unable to read and verify install manifest /archive/play/steam-games/package/steam_client_ubuntu12.installed
[2018-09-19 16:40:22] Verification complete
[2018-09-19 16:40:22] Downloading update...
../tier1/fileio.cpp (3186) : Assertion Failed: Failed to determine free disk space for ., error 75
[2018-09-19 16:40:22] Error: Steam needs 250MB of free disk space to update.
[2018-09-19 16:40:22] Error: Steam needs to be online to update. Please confirm your network connection and try again.
Same issue for me.
Went a head and did the quota.
Would like a proper fix.
There seem to be two issues here:
- EOVERFLOW being returned by the kernel is likely fixed by this mainline patch:
https://patchwork.kernel.org/patch/9987759/
- The original issue where 'Steam "needs at least 250MB" free space when plenty of space' is likely the steam code scaling the free block reported by statvfs64 into a 32-bit unsigned integer with a 512-bit block size. The only workarounds there at this time are reducing either how much free space is available or reducing the amount of freespace that is reported with a LD_PRELOAD trick.
It would be awesome if valve would fix this. In the interim, would someone affected by this test the LD_PRELOAD wrapper that I posted based on @tchebb's earlier LD_PRELOAD wrapper?
/*
* Intercept calls to statvfs64(), which is used by Steam to determine
* free disk space, and indicate that all space is available. This is
* needed to work around the fact that Steam checks available disk space
* before it checks for existing files.
*
* Please ONLY use this preload when you need it to install a game, then
* relaunch Steam without it so that disk space detection works again.
*
* To compile:
* gcc -shared -fPIC -m32 -o fakefree.so fakefree.c -ldl
*
* To use (after ensuring Steam is not running):
* LD_PRELOAD=<path-to-fakefree.so> steam
*
* This code is Public Domain.
*/
#define _GNU_SOURCE
#include <stdlib.h>
#include <limits.h>
#include <dlfcn.h>
#include <sys/statvfs.h>
void limitField(fsfilcnt64_t *field, fsfilcnt64_t size)
{
if (*field * size > (((fsfilcnt64_t)INT_MAX) << 9)) {
*field = (((fsfilcnt64_t)INT_MAX) << 9) / size;
}
}
int statvfs64(const char *path, struct statvfs64 *buf)
{
static int (*real)(const char *, struct statvfs64 *) = NULL;
if (real == NULL)
real = dlsym(RTLD_NEXT, "statvfs64");
int ret = real(path, buf);
limitField(&buf->f_bfree, buf->f_frsize);
limitField(&buf->f_bavail, buf->f_frsize);
return ret;
}
The idea of putting a workaround into ZFSOnLinux is under consideration at openzfs/zfs#7927, provided that we cannot get Valve to fix this. Feedback on whether that LD_PRELOAD wrapper helps from someone affected by this would be helpful.
@kisak-valve It would be appreciated if you would poke your contacts at Valve to get this fixed so that other projects don't need to implement workarounds. It ought to be fairly simple for one of Valve's developers to fix.
@kisak-valve It would be appreciated if you would poke your contacts at Valve to get this fixed so that other projects don't need to implement workarounds. It ought to be fairly simple for one of Valve's developers to fix.
ryao have you tried the beta client yet? the most recent update for it on my system broke writing to the disk on nfs. not sure if this is related to either of those 2 bugs mentioned. it creates folders and then when trying to download updates/games it errors that it cant write to the download folder.
I have the same problem, also running ZFS with 4TB of free space. Could this be related to a glibc update?
Same problem. Linux Mint 19 AKA Ubuntu 18.04 with ZFS dataset mounted at /mnt/steam with 777 permissions (shouldn't be necessary but was trying to get this to work).
I have 4.5 TB of free space. And proper rights. I just copied and removed a movie in my username to the ZFS dataset.
This setup works on my other machine. Frustrating. Did something change since a steam update?
@kisak-valve over the years I've seen this issue in one form or the other more often than I care for. Please please please add the option to ignore free disk space checks. Tuck it away as far as you like, but let there be a way.
This setup works on my other machine. Frustrating. Did something change since a steam update?
@kisak-valve over the years I've seen this issue in one form or the other more often than I care for. Please please please add the option to ignore free disk space checks. Tuck it away as far as you like, but let there be a way.
Redsandro have you tried the beta client? im getting worse results with that. It complains it cant write files.
It is still outstanding as of latest Steam Beta and 4.19.0 kernel. ZFS changes are approved for 0.7.12. There's still implementation time after though. Valve could make this go away if they capped the freespace at something sane.
This drove me a bit insane to the point I have a zfs filesystem for each title with a quota on their parent steamapps directory. On the plus side it allows for easy snaphots and moving data around to other hosts/vms (yay zfs send), but is a completely external process.
The ZFS recordsize is possibly a red-herring as my home directory is mounted via NFSv4 and I'm now having the same issue after upgrading from Ubuntu MATE 16.04 to 18.04.
My NFS server is using ZFS for the datastores, but I don't believe that's relevant on the client.
I do have 4.2TB free in my home filesystem.
Edit: I did as ryao suggested and created a separate filesystem with a 2T quota at ~/.local/share/Steam, then linked ~/.steam to it, and that seems to work so far. I only launched Steam and made sure it installed cleanly and got to the login prompt.
Edit 2: Confirmed, this workaround works for those of us with ZFS on the back end (I don't know if the same is possible in btrfs).
In case someone else finds this issue like I did: I'm running steamcmd inside a docker container on a host with zfs and I worked around this error by adding --storage-opt size=100G to my docker run command. This was easier than changing quotas since my container isn't using a volume.
Can you run stat -f [nfs mount] on your nfs client system, do the same on the server side for the backing partition, and report the results?
Can you run
stat -f [nfs mount]on your nfs client system, do the same on the server side for the backing partition, and report the results?
On my desktop, my home directory (which will cause the failure, had to move it from here):
ID: 0 Namelen: 255 Type: nfs
Block size: 1048576 Fundamental block size: 1048576
Blocks: Total: 4011490 Free: 3245823 Available: 3245823
Inodes: Total: 6649115851 Free: 6647444480
Same directory on the (ZFS) NFS server:
ID: 4d5001200000000 Namelen: 255 Type: zfs
Block size: 131072 Fundamental block size: 512
Blocks: Total: 8215529376 Free: 6647443120 Available: 6647443120
Inodes: Total: 6649114491 Free: 6647443120
Again on the desktop, the directory in which Steam is now installed (and working, see below):
ID: 0 Namelen: 255 Type: nfs
Block size: 1048576 Fundamental block size: 1048576
Blocks: Total: 2097152 Free: 1926086 Available: 1926086
Inodes: Total: 3944791494 Free: 3944622648
On the server (this is a ZFS filesystem in the same zpool, but with 2TB quota/size restriction workaround applied):
ID: 4d5001300000000 Namelen: 255 Type: zfs
Block size: 131072 Fundamental block size: 512
Blocks: Total: 4294967296 Free: 3944622648 Available: 3944622648
Inodes: Total: 3944791494 Free: 3944622648
@glabifrons thanks - if you are up for a little more testing, would you mind reaching out to me directly?
Latest steam beta (Nov 7) comes with several changes to the way the client obtains free disk space information, which may help with this - please retest.
If you are still experiencing this bug, please set DBG_STAT environment variable before running steam and provide the diagnostic output to statfs64 and statvfs64 calls from Steam client stdout.
Multiple games will tell me that they are out "Out of Space" (most recently, "Oxygen Not Included" will eventually fail (after six hours of play or so) to save any more games, complaining that "At least 15MB of space must be available."
Meanwhile, I am on XFS, and have at least 70G available (and millions of inodes.)
Restarting the game "resolves" the issue, but why is this even a thing?
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 233G 161G 72G 70% /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 121883136 1707103 120176033 2% /
@AlbinoGeek would you mind running disk-free.sh out of https://www.dropbox.com/s/7s02hqms6ewzoim/disk-free.tgz?dl=0 and reporting the results.
I'm mostly interested in the provided 'scout' binaries (e.g. steam-runtime) - source code is included too.
Basically we think statvfs64 is broken for 32 bit binaries on a variety of partitions (XFS/NFS) - I'm not sure if it's a libc or kernel problem. We'll implement a fix in the Steam client but it's unlikely we'll be able to fix individual games.
SCOUT x86
statvfs64: ret 0 errno 0
f_bsize : 4096
f_frsize: 4096
f_blocks: 60911812
f_bfree : 17948682
f_bavail: 17948682
statfs64: ret 0 errno 0
f_type : 1481003842
f_bsize : 4096
f_blocks: 60911812
f_bfree : 17948682
f_bavail: 17948682
SCOUT x64
statvfs64: ret 0 errno 0
f_bsize : 4096
f_frsize: 4096
f_blocks: 60911812
f_bfree : 17948682
f_bavail: 17948682
statfs64: ret 0 errno 0
f_type : 1481003842
f_bsize : 4096
f_blocks: 60911812
f_bfree : 17948682
f_bavail: 17948682
BIONIC x86
statvfs64: ret 0 errno 0
f_bsize : 4096
f_frsize: 4096
f_blocks: 60911812
f_bfree : 17948682
f_bavail: 17948682
statfs64: ret 0 errno 0
f_type : 1481003842
f_bsize : 4096
f_blocks: 60911812
f_bfree : 17948682
f_bavail: 17948682
BIONIC x64
statvfs64: ret 0 errno 0
f_bsize : 4096
f_frsize: 4096
f_blocks: 60911812
f_bfree : 17948682
f_bavail: 17948682
statfs64: ret 0 errno 0
f_type : 1481003842
f_bsize : 4096
f_blocks: 60911812
f_bfree : 17948682
f_bavail: 17948682
No difference. Does Steam run anything under a chroot or similar system? Is there any library redirection in play, or anything else that would result in a game executing out of a virtual filesystem? (This is a wild guess, but seeing snap and friends do this...)
@AlbinoGeek thanks.
From the Steam client perspective you should be set and it will understand that you have 70GB free on your root XFS partition just fine.
We can't fix the game titles though, you will need to report to each developer individually that they should either provide a 64 bit version of their title or switch their 32 bit implementation to use the _LARGEFILE64_SOURCE APIs.
Next client beta (> Nov 28) will have an additional workaround for this situation: torvalds/linux@cc3a7bf#comments
Hopefully this will address the remaining problems.
Closing as fixed in the 2019-12-16 Steam client update.
If anyone is still seeing this issue, it will need a new investigation.
not too sure how you think this is fixed 80Tb free and steam thinks it can not install anything
it just looks at free space under the home folder and ignores all free space on root
not too sure how you think this is fixed 80Tb free and steam thinks it can not install anything it just looks at free space under the home folder and ignores all free space on root
Your comment is confusing.
Why would you have 80Tb (guessing you actually mean TB) free on root? Surely you mean home.
Why should Steam look to the root filesystem instead of where it's actually storing the files (in your home)?
Aside from that, please see the comment from @kisak-valve (posted >3 years ago)... you need to open a new Issue.
not too sure how you think this is fixed 80Tb free and steam thinks it can not install anything
it just looks at free space under the home folder and ignores all free space on root
not too sure how you think this is fixed 80Tb free and steam thinks it can not install anything it just looks at free space under the home folder and ignores all free space on root
Your comment is confusing. Why would you have 80Tb (guessing you actually mean TB) free on root? Surely you mean home. Why should Steam look to the root filesystem instead of where it's actually storing the files (in your home)? Aside from that, please see the comment from @kisak-valve (posted >3 years ago)... you need to open a new Issue.
why wouldn't I have 80TB ?
and I do not have my steam library in my /home either .... but that is what is seems to only use for free space checking
You're complaining that it's checking your home - that's because that's where it stores the library.
It looks for free space where you tell it to install the game. Why would it check somewhere else?
If you've configured Steam to store your library in another path by default, you should say so, and more importantly, state where. This is critical information you're leaving out.
You said you have 80TB in root, yet your screenshot clearly shows your root has 15GB available. Still a lot, but 3 orders of magnitude different (and just as irrelevant as that's not where Steam stores your games).
Your home has 2.8GB available which should be enough for small games, but don't expect a AAA game to fit there.
In fact the only filesystems that have availability listed in the terabytes range are in non-standard mount points.
Why would you expect Steam to check there?
No-one can guess your configuration. If you want help, you're going to have to provide more info as to what custom configuration you've come up with.