So, I discovered weird behavior when trying to play games on an NTFS file system in Linux.
When i auto mount the drive through a fstab entry, it is only able to launch Linux native games (I think I read somewhere that this is a permission issue).
However, if I mount it through steams “select a drive” option, it works without a problem (so far at least).
I assume this is again a permission issue, as when I mount the drive through steam, I get a Polkit password prompt.
Anyone got a clue what’s going on, and/or maybe a way to make the auto mount work, so I don’t have to manually mount it after every boot?
Distro:
Arch
Kernel (according to neofetch):
6.11.1-zen1-1-zen
NTFS driver:
ntfs-3g
Proton version:
GE-Proton9-10
tested games:
- Terraria (Tmodloader)
- Project Wingman
- Hades II
fstab entry:
#/dev/nvme1n1p1
UUID=E01A2CEC1A2CC180 /mnt/games ntfs nofail 0 3
full system update a few hours ago
date for future visitors (dd.mm.yyyy):
01.10.2024 at 14:44 (02:44 pm)
edit: formatting and adding proton version
NTFS doesn’t support symlinks, so it doesn’t work correctly from NTFS partition. Also it is possible that you can corrupt those files on NTFS partition by doing that.
Basically don’t mix Windows stuff with Linux stuff when running programs. It’s okay for media.
Yeah it’s just games🤷 if push comes to shive i can just reinstall 'em i was just confused by the difference in behaviour depending wether the system or steam mounts it
Well, technically Steam expects a file system to act as a Linux file system. Since some features that Linux file systems support do not exist on NTFS, it doesn’t work correctly.
By the way, if you’re gonna use Proton for a game, you can backup and reinstall it by using that backup on Linux. You don’t have to download it again.
no thats the thing, steam works without a problem. it is only when i do it NOT through steam where i get issues.
but i play mainly on windows anyway, i just wanted to try it out a bit out of boredom and got surprisingly good results.
i just wait how the windows kernel restrictions influence kernel level anti cheat, and depending on the result i may switch to full linux again if kernel AC breaks and devs are forced to use “normal” AC again
NTFS doesn’t support symlinks
It does. You can create them on Windows using the mklink command. It creates a file link if no switch is passed, directory link with /D, directory junction (different thing) with /J, and hardlink with /H. The ntfs-3g driver has complete support for links.
Some Windows programs, like the Scoop package manager, make extensive use of symlinks and directory junctions.
Huh, interesting. Didn’t know about mklink. So with this, can Steam games be used from NTFS directory?
Not really, because some files in the wineprefix will have invalid names.
When an NTFS volume is mounted, it implicitly uses the windows_names option, which restricts the character set that can be used in filenames, in order to preserve compatibility with Windows. The specific character in question is the colon – it is permitted by NTFS, but it’s a reserved character in Windows, which means it is also restricted by the windows_names mount option. This prevents Wine from creating its c: and z: symlinks, which are required for Wine to operate.
You could try some symlink fuckery, like linking .../steamapps/ to the NTFS drive, since all of the problematic files are located outside of that, in .../steamapps/compatdata. Or you could mount the NTFS volume directly to the common directory. If you do, I’d love to hear the results.
Relevant issue: https://github.com/storaged-project/udisks/issues/713
