Yes, I read your comment. It’s okay if you didn’t understand my comment. Clearly you don’t understand how filesystems and drive mounting works under Linux or the role of desktop environments in managing filesystems, mounting, and permissions. I don’t doubt that you’re genuinely struggling here, but there is no call for that kind of hostility. You might have some hope for figuring it out if you open your mind to the fact that you don’t fully understand what your problem is.
Steam expects the games to be in a particular place with a particular set of permissions and ownership relative to the user(s) and/or group(s) expected to use those game files. I’m telling that Linux doesn’t care where those files physically reside. You can tell Steam that those files are exactly where Steam expects them to be at the filesystem level, without messing with Steam configs, nautilus, gnome, or KDE. There are several ways to do this, but without understanding the requirements of your machine no one here will be able to give you effective advice.
I’ve seen some other comments from you about running something or other as root or just blanket chmods to 777 and I can tell you from experience that those are rarely effective solutions and can sometimes make things worse (just try something like that when configuring ssh configs, keys, and permissions).







Ever really destroyed your server because the it needed were available? I have. It was so much worse than a boot process that froze.
If Systemd was pausing due to a network share being down, it’s only because I (or you) told it to do exactly that. There are lots of good reasons to delay the boot process until all drives the system expects to be there are actually there or the network is up. Cleaning up the mess that happens when the system does not check these kinds of things at boot is so much worse. It’s never really some nebulous thing. Like it or not, intentional or not, the machine is doing exactly what you asked it to do and a delayed boot or a boot halted until you can solve the real problem is almost always better (or at least safer) than the alternatives. I’ve experienced all the things you’ve mentioned, dealt with each of those issues, and it was so much more of a hassle to diagnose before Systemd.