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
UPDATE: This can be a possible solution, but might not be what OP needs.
Wineprefixes don’t work right on NTFS filesystems because some files contain colons, which is a reserved character in NTFS and FAT.
If you look inside the game’s wineprefix, the
dosdevicesdirectory will typically have two symbolic links: one namedc:that points to thedrive_cdirectory, and another namedz:that points to the filesystem root (plus a few others that are irrelevant). These will appear as lettered drives for programs running inside Wine. If the wineprefix is on an NTFS partition, those files can’t be created because their names contain an invalid character.You’ll have to either relocate the wineprefixes to an ext4 or btrfs partition (I don’t know if you can do that on Steam), or format the NTFS drive using ext4 or btrfs.
It’s not related to the issue, mounting a device usually requires elevated privileges. The same thing happens when it is mounted through fstab, except the process that mounts it already has elevated privileges. Access to the filesystem is not affected by this.
Ah ok i think i get why it doesn’t work through the auto mount, but i still don’t understand why it works completely fine if i mount it through steam? What is different when steam mounts it?
I don’t know for sure, but I have an idea.
By default, Steam creates wineprefixes in
~/.steam/steam/steamapps/compatdata/GAME_ID. This is located in the user home, which should be a Linux filesystem (ext4, btrfs, and similar). If the drive is mounted statically through fstab, the prefixes are created on the mounted drive. If the drive is mounted dynamically, Steam might think it’s a USB stick, likely with a FAT32 filesystem, and preemptively create the prefixes inside the user home to ensure compatibility.I’ll have to do some testing once I get home.
This could very well be the anwser. there are in fact c: and z: in
~/.steam/steam/steamapps/compatdata/0/pfx/dosdevicesalthough i couldn’t find an indicator that those are actually in use when launching a game through steam
They’re definitely both used. When a program is started in a Wine environment, those symlinks are the only way it can access the filesystem: game files in
.../steamapps/commonthroughz:; settings and saved games (normally in the Windows user’s home directory) throughc:.You can run
wine explorer.exeto open a Windows Explorer implementation and check out what the Linux filesystem looks like in Windows. You can even add new lettered drives usingwinecfg, although I wouldn’t try it with Steam’s prefixes.