3

Trying to figure out if there was an update recently that has affected steam's wine compatibilty tool proton from working correctly.

I have been gaming on this machine for a couple years, but as of about a week ago, anything that requires proton no longer works. I've been messing around with different proton versions and launch settings, can get apps to partially start, but in general everything either crashes or doesn't fully launch.

I noticed a bunch of the python libraries it uses got updated. Any help appreciated.

Running Ubuntu 20.04.4 AMD Ryzen 5 3600 AMD Radeon rx5700

Hearth
  • 343
  • 1
  • 3
  • 8

2 Answers2

0

I had this problem around the same time frame with very similar hardware, but I just got it fixed today! This probably isn't the only solution or the best solution, but it is a solution that works.

To fix this, I re-installed Ubuntu, using the newly released 22.04 LTS version. My steam library was on a separate hard drive and the games that previously didn't work now do. If you don't want to switch to 22.04, you might be able to get it to work again on 20.04, but I didn't try that. My guess is that it's a python dependency problem or some problem with wine, but again, I haven't verified it.

Things that I tried that didn't work:

  • Uninstalling and re-installing Steam
  • Uninstalling and re-installing each proton distribution
  • Uninstalling and re-installing particular offending games

Hope this helps!

Nathan
  • 9
0

In general, to narrow down things it helps to run steam from a terminal (to see its log output) and enable proton logging via the corresponding environment variable, i.e.:

PROTON_LOG=1 steam

In my case the issue was that all games were immediately closing after pressing the "Play" button, without any window popping up, as described in this reddit thread as well.

With debug logging enabled, running any game creates a file ${HOME}/steam-<PID>.log, which contained the error:

wine: /path/to/mountpoint/Steam Library/steamapps/compatdata/22200/pfx is not owned by you

And indeed, I was mounting my NTFS disk in a way that the files were owned by root, i.e., without specifying uid/gid. This issue has also been reported here on GitHub. I could solve this particular issue, by changing the fstab entry to something like:

/dev/disk/by-uuid/<DISK-ID> /path/to/mountpoint ntfs-3g nosuid,nodev,nofail,x-gvfs-show,uid=1000,gid=1000 0 0

See also this question for mounting NTFS modules.

bluenote10
  • 1,885
  • 1
  • 18
  • 23