Adding library with flatpak filesystem override also requires parent folder access, will fail otherwise, can be removed after library creation

[MateusRodCosta]

Your system information

• Steam client version (build number or date): 1707518866
• Distribution (e.g. Ubuntu): Fedora Silverblue 39 - Steam Flatpak
• Opted into Steam client beta?: [Yes/No] Yes
• Have you checked for system updates?: [Yes/No] Yes
• Steam Logs: [generate by running this command in a terminal tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs] N/A?
• GPU: Nvidia/Intel/AMD - NVIDIA GTX 1660 TI/ Intel UHD 630 (Nvidia Optimus system)

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist

By default Steam flatpak creates its Library in /var/home/mateusrc/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps however due to a crash with a game that has issues with alrge paths (Dragon's Dgoma: Dark Arisen) I had to try to move it to a new library someplace else that results in a shorter path.

I wanted to create a new library at ~/Games/SteamGames, but by allowing Steam access to only that folder via Flatseal and trying to add the library it always fails. It turns out that if I first allow access to ~/Games via Flatseal, create the library and then go back to only allowing ~/Games/SteamGames it works as expected.

So, ultimately adding a library requires access to the parent folder but once the library is created it isn't required anymore. There is also no error message explaining this properly.

Steps for reproducing this issue:

1. Create a folder such as ~/Games/SteamGames
2. Allow ~/Games/SteamGames on Flatseal
3. Try to turn ~/Games/SteamGames into a Library
4. Notice how it will refuse to with no reason why
5. Allow ~/Games on Flatseal
6. Try to turn ~/Games/SteamGames into a Library
7. Notice how now you are able to create the library
8. Revert the permission to only ~/Games/SteamGames
9. Library keeps working

[smcv]

I wanted to create a new library at ~/Games/SteamGames, but by allowing Steam access to only that folder via Flatseal and trying to add the library it always fails. It turns out that if I first allow access to ~/Games via Flatseal, create the library and then go back to only allowing ~/Games/SteamGames it works as expected.

I'm surprised by this. Flatpak will normally create whatever empty directories are necessary to act as mount points, either in the per-Flatpak-app fake home directory (in your case /var/home/mateusrc/.var/app/com.valvesoftware.Steam) or in the Flatpak app's root filesystem (which is a tmpfs).

Does the path to ~/Games/SteamGames involve any symbolic links? From the fact that you mention /var/home, I suspect you might have /home -> var/home?

My usual test setup for the Steam Runtime has the majority of my test games in ~/SteamLibrary, shared with the Flatpak app via flatpak override --user --filesystem=~/SteamLibrary com.valvesoftware.Steam (which is the equivalent of what Flatseal does), and that works fine.

Notice how it will refuse to with no reason why

What precisely do you mean by "it will refuse"? Is there an error message, or is a piece of UI disabled/greyed-out, or what?

[MateusRodCosta]

@smcv

Does the path to ~/Games/SteamGames involve any symbolic links? From the fact that you mention /var/home, I suspect you might have /home -> var/home?

Let me explain how it is setup.

I run Fedora Silverblue, so by default it creates 3 btrfs subvoluems: root (mounted on /), var (mounted on /var) and home (mounted on /home). Due to it being a Fedora Atomic variant, /home is a symlink to /var/home.

So I also decided to create a ~/Games subvolume and move all gaming stuff to it, and then a ~/Games/SteamGames to be able to play Dragon's Dogma (the game crashes if ran from a long path such as the one default for flatpak Steam library).

What precisely do you mean by "it will refuse"? Is there an error message, or is a piece of UI disabled/greyed-out, or what?

I don't remember very well, but I think it just refuses do anything and doesn't even pops out an error message, I think it just returned me to the previous screen.

My usual test setup for the Steam Runtime has the majority of my test games in ~/SteamLibrary, shared with the Flatpak app via flatpak override --user --filesystem=~/SteamLibrary com.valvesoftware.Steam (which is the equivalent of what Flatseal does), and that works fine.

The thing is, if I create the library the way I said on the issue, it works fine for downloading games.

The weird thing is that I, if I only give it access to ~/Games/SteamGames without also giving access to ~/Games, Linux native games will run fine but Proton games will fail. If I then add at least ro access to ~/Games alongside access to ~/Games/SteamGames, then it will work fine.

Interestingly, this seems to be the error related to this:

fev 19 13:02:29 centauro steam-runtime-launch-client[32028]: E: Unable to convert /app fd 16 into path: different file inside and outside sandbox

Maybe it's the fact that it's a btrfs subvol inside another subvol that is causing the issue?

[smcv]

What precisely do you mean by "it will refuse"? Is there an error message, or is a piece of UI disabled/greyed-out, or what?

I don't remember very well, but I think it just refuses do anything and doesn't even pops out an error message, I think it just returned me to the previous screen.

I am not a Steam client user interface developer, so I will not be able to solve this for you in any case; but I suspect that to be able to solve this issue, a UI developer would need to see either an error message, or a clear description of what happens if you reproduce the problem.

Steam's logs (the ones the issue template asked for) might contain useful information. When using the Flatpak app, as a result of the Flatpak sandboxing they will end up in a path like /var/home/mateusrc/.var/app/com.valvesoftware.Steam/.local/share/Steam/logs.

Maybe it's the fact that it's a btrfs subvol inside another subvol that is causing the issue?

You could test that theory by creating ~/SteamIssue10487/TempSteamGames as ordinary directories, giving Steam access to the inner directory, and trying to make that a Steam library and install a small game into it. My guess would be that btrfs subvolume vs. ordinary directory won't actually make a difference here.

[smcv]

if I only give it access to ~/Games/SteamGames without also giving access to ~/Games, Linux native games will run fine but Proton games will fail

I think this is likely to be a separate problem, not the same as the UI issue in setting up a new library, which we should discuss in a new https://github.com/ValveSoftware/steam-runtime/ issue report. I am more likely to be able to solve this than Steam Client UI issues.

Now that you have quoted the error message steam-runtime-launch-client[32028]: E: Unable to convert /app fd 16 into path: different file inside and outside sandbox, we have something to work with. Please capture a log (see instructions) which will give us more information, and attach it to a new steam-runtime issue report or link it as a Gist.

Due to it being a Fedora Atomic variant, /home is a symlink to /var/home.

This might well be a factor: symbolic links tend to be annoying across container boundaries, because their meaning is different inside and outside the container. Flatpak and the Steam Linux Runtime container framework both try to take symlinks into account and make everything work, but there are probably corner cases that still don't.

Does the path /var/home/mateusrc/.var/app/com.valvesoftware.Steam/Games/SteamGames involve any symlinks, or is it 100% "real" directories? You should find that Games and SteamGames are either symlinks or "real" directories, because Flatpak needs to create those so that it can mount filesystems onto them. If there are any symlinks, what are they, and what are their targets?

Similarly, are /var/home/mateusrc/Games and/or /var/home/mateusrc/Games/SteamGames symlinks or "real" directories? And if they are symlinks, what are their targets?

Linux native games will run fine but Proton games will fail

I suspect the problem is actually that games that run under the legacy LD_LIBRARY_PATH-based Steam Runtime will work fine, but games that require the Steam Linux Runtime container (Proton and some native Linux games) will not. You could test this by taking a game that usually works (preferably something small, Floating Point is my usual example of a free, trivially small game), and in Properties -> Compatibility, setting it to use "Steam Linux Runtime 1.0 (scout)". If my guess is correct, it will fail, with a similar error message.

Again, let's discuss this problem with launching games on a new https://github.com/ValveSoftware/steam-runtime/ issue report rather than here, because it can hopefully be fixed independently of anything that might be a problem in the Steam client UI.

[MateusRodCosta]

It seems the issue with creating the library without giving access to the parent folder is gone? So I will just focus on the steam-runtime issue now.

[MateusRodCosta]

I believe the GUI issue with creating a library wasn't an actual issue or might have been caused by Steam being sometimes unresponsive to clicks (possibly a Xwayland issue?)

So, I think this either wasn't a issue before or isn't anymore. I have filled a separate issue for the possible steam runtime issue I might have uncovered.