Can't read files from mounted drive in certain situations

Hi everyone,

Recently started dual-booting Manjaro with Windows 10, on the same drive. The thing is, I’m trying to get into Linux gaming, and obviously, Steam/Proton is a major part of that. So far, downloads I’ve tried have worked swimmingly, but those were only to the same drive (my C:, or /dev/sda) on which I installed Manjaro.

I tried to start downloading games on to another drive (the D:, or what appears to be listed as /dev/sdc, which I generally use on Windows for most of my installations that don’t absolutely HAVE to be on C:), as File Manager says it’s already mounted, and sure enough, Steam allows me to download to that drive.

Here’s the problem, though: even though the drive is apparently mounted, and even though I can indeed access files on that disk in both OSs (and download them to it), any game I attempt to run directly from that drive immediately crashes, or worse yet, doesn’t even start at all. Yet when I transfer the installation back to /dev/sda, it works perfectly. What’s going on? Is my drive not mounted properly, or is it something else? Any help would be greatly appreciated.

What you have to understand, first and foremost, is that GNU/Linux is not Microsoft Windows, and was also never meant to mimic Windows ─ it’s a UNIX system, and its intent has always been to be an alternative to proprietary UNIX systems, e.g. IBM AIX, SCO Unix, SGI IRIX, HP/UX, et al. Therefore, if you approach GNU/Linux as a Windows-like system ─ as you appear to be doing, given your mention of drive letters ─ then you are going to run into a couple of strange surprises.

GNU/Linux is a UNIX operating system, and therefore its filesystems use and store POSIX file ownership and permissions. Microsoft Windows is not compatible with those, and the Windows NTFS filesystem does not store POSIX ownership and permissions on-disk.

This means that when an NTFS filesystem is mounted into the UNIX directory hierarchy, POSIX ownership and permissions must be faked in the kernel’s virtual filesystem layer. They are applied to the entire filesystem at mount time, and they cannot be altered on a per-file basis. They are also not stored when the filesystem is unmounted again.

Now, there are two ways through which a filesystem can get mounted in GNU/Linux. The first way is through a static record for the filesystem in /etc/fstab. The second way is on-the-fly, by the plug & play functionality of the device manager ─ more specifically, by the udisks subsystem of systemd.

And given that this is an on-the-fly mount, the permissions may not always be consistent. This ties in with the fact that in Microsoft Windows, a file is executable if its name ends in a certain three-letter suffix ─ e.g. .exe ─ which is a legacy from the days of MS-DOS and CP/M, two single-user, single-tasking operating systems for standalone computers without a network connection.

UNIX on the other hand was designed from the ground up as a multiuser platform, and in UNIX, whether a file is regarded as executable or not depends on the POSIX permissions of the file ─ there are three main permissions, read , write and execute, and three groups of such permissions, i.e. for the owner of the file, for the group that owns the file, and for all others.

Combining this with the ad-hoc mounting by udisks, those permissions are faked at mount time, and are not guaranteed to remain consistent across multiple mounts, among other things due to system updates that introduce revised security policies, et al.

And quite often ─ not always but often ─ the automatic mounting of an NTFS filesystem by way of udisks will for security reasons not set an execute permission for the files on the NTFS filesystem, given that it is after all an alien filesystem, and that any executables residing thereon could potentially undermine the stability of the operating system.

So, long story short, when your games are installed on NTFS, then they probably don’t have execute permission, whereas when they are stored on your Linux-native filesystem ─ I presume it’s ext4, which is the default in Manjaro ─ they do have execute permission, even if only because the permissions and ownership are physically stored on the filesystem.

:man_shrugging:

2 Likes

Fair enough. I assume it’s not as simple as finding a way to forcibly assign those permissions, so would it be possible instead to run installed games off of a newly-formatted drive? For instance, an external SSD, provided that I formatted it in Manjaro beforehand? Or will this be an issue no matter what?

Again, I apologize if this is a question with an obvious answer; I’m still quite new to Linux in general.

If you format it as ext4 and if you set the permissions right so that you have write access to the filesystem ─ e.g. by setting it up with a mountpoint under your $HOME ─ then that should work.

1 Like

Thank you again for the help; sorry it took me so long to reply. At the moment, I can’t purchase an additional SSD to try this on, but the logic is sound (as if you need a complete beginner to tell you that lol), and the advice is explicit and straightforward, so I’ve marked this as a solution. I really appreciate the advice! :+1:

1 Like

@M.Cleland

Had the same problem with XFCE

Gnome is Better

:grinning: