In my flake config, installing Steam is as simple as programs.steam.enable. However, I have a machine with two hard drives: my main drive (1TB SATA SSD) contains the NixOS installation (the nix store) and an unused 500 GB nvme drive. I have configured the nvme drive to mount in /media/mydrive and uses an ext4 file system
If I understand correctly, the FHS environment where Steam gets installed is in the nix store so that might be an issue if I want the whole steam installation to be in another drive.
If that’s impossible, I want the game installtions to be stored in the extra drive instead while leaving the main steam installation on the main drive
If that’s impossible, I want the game installtions to be stored in the extra drive instead while leaving the main steam installation on the main drive
I’m not sure about possibility of your main ask but I do install my games on another drive.
Yeah, I just set up a second library with the usual steam settings for that. This is NixOS’ FHS “container”, it’s not sandboxed like a flatpak, it mostly behaves as if the binary is just running normally.
Can you please share your configuration or your workaround.
Navigating to Steam > Settings > Storage, clicking Add Drive opens Steam’s popup to select a new library folder but all the buttons are clickable but non-functional except for the Cancel button
I forgot I had to do something silly to get steam to see the drive. I should have mentioned that in my first post. Many apologies. I’m trying to remember - ugh, it was silly.
Oh yeah, it had something to do with xdg see here: Unable to add new library folder to steam - you should check you system journal to confirm but you’ll likely see steam trying to open something via the portal or whatever. I dunno the proper terminology
With ext4, btrfs and other filesystems that natively support unix users the best way is to set the owner of the root directory immediately after you formatted the partition. They retain the UID/GID you set, so mount doesn’t have any options to change them (and shouldn’t, you’d change all the data on the disk if you mounted it with such a hypothetical option).
To do that declaratively, you’d need to use disko and do it at installation time, but I’m not sure it has an option for such a thing (disko did not exist when I set up my steam partition). Maybe worth raising as an issue if not.
You can set up a systemd unit that depends on the specific mount and then recursively runs chown on it, but you probably don’t want that in case you put files on the filesystem whose user is deliberately set to something rlse.
For non-unix filesystems, you can use fileSystems.options to change the owner.
Alternatively, I guess there might be a way to mount the disk on user login with udisks somehow?
There is no mount option that can change it, but regular user manipulation commands work. Just sudo chown user:group whatever files and directories on the drive you want to change - you will only need to do that once until you reformat the disk since the permissions are stored with the files.
There is no mount option to change it because the user is stored with the files, not filesystem properties. That’s what your stackexchange answer says, too.
You cannot format a disk as a non-root user, so it will always be root-owned after initial setup. Therefore, I consider setting the desired user as part of the initial formatting, so if you do that imperatively you should also change the user imperatively.
If you want to format your drives declaratively (and as part of that change the owner of the root directory on them), use disko. But you already have a fully formatted and installed system, so just change that ownership imperatively rather than reinstalling your system just so you can make your partitioning declarative (but remember you can do this for your next computer or reinstall).
The alternative is setting up a systemd unit that just automatically changes the owner of all files on the disk every time you mount it. That can be set up to happen declaratively, but I don’t think it’s the right solution.