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

  • rtxn@lemmy.worldEnglish
    0·
    2 months ago

    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 dosdevices directory will typically have two symbolic links: one named c: that points to the drive_c directory, and another named z: that points to the filesystem root. 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.

    when I mount the drive through steam, I get a Polkit password prompt

    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.

    • SaltyIceteaMaker@lemmy.mlOP
      0·
      2 months ago

      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?

      • rtxn@lemmy.worldEnglish
        0·
        2 months ago

        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.

        I’ll have to do some testing once I get home.

        • SaltyIceteaMaker@lemmy.mlOP
          0·
          2 months ago

          This could very well be the anwser. there are in fact c: and z: in ~/.steam/steam/steamapps/compatdata/0/pfx/dosdevices

          although i couldn’t find an indicator that those are actually in use when launching a game through steam

  • rtxn@lemmy.worldEnglish
    0·
    2 months ago

    I’ve done my tests, and it looks like I may have been incorrect.

    While I was right to suspect the : character, I discovered that it is permitted in NTFS and only reserved in Windows. When an NTFS volume is mounted in Linux, it only becomes a problem if the windows_names option is used. Sometimes it is used, sometimes it isn’t, and I don’t know when.

    The other thing I found is that Wine only works if the wineprefix is owned by the user. NTFS doesn’t understand Unix-style file ownership and permissions, so it must determine the uid, gid, and umask when the volume is mounted. When mounted with OP’s fstab entry, it will default to root, so every file (including the wineprefixes) within the volume will appear as being owned by root, which prevents Wine from starting.

    This might also explain why mounting the drive dynamically worked, as it probably used udisks2 to mount it as the user.

    The solution may be as simple as specifying the uid and gid mount options. In a system with a single user, they should both be 1000, but you can check them by running echo $UID $GID.

    The modified fstab entry should be:

    UUID=E01A2CEC1A2CC180 /mnt/games ntfs nofail,uid=1000,gid=1000 0 3

    This will present all files as being owned by the user, and should allow wine to run.

  • muhyb@programming.dev
    0·
    2 months ago

    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.

    • rtxn@lemmy.worldEnglish
      0·
      2 months ago

      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.

      • muhyb@programming.dev
        0·
        2 months ago

        Huh, interesting. Didn’t know about mklink. So with this, can Steam games be used from NTFS directory?

        • rtxn@lemmy.worldEnglish
          0·
          2 months ago

          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/common 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

    • SaltyIceteaMaker@lemmy.mlOP
      0·
      2 months ago

      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

      • muhyb@programming.dev
        0·
        2 months ago

        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.