Hi @kisak-valve

I had read that issue you mentioned, I think that issue is very similar to this.
However, I couldn't understand what I should do to fix this because that's author commented:

I'm not sure what did it to be exact...

I checked mounts

$ grep /run/user /proc/$(pidof -s steam)/mounts
tmpfs /run/user/60331 tmpfs rw,nosuid,nodev,relatime,size=3255252k,nr_inodes=813813,mode=700,uid=60331,gid=60331,inode64 0 0

$ grep /doc /proc/$(pidof -s steam)/mounts
portal /run/flatpak/doc fuse.portal rw,nosuid,nodev,relatime,user_id=60331,group_id=60331 0 0

Today I noticed that /run/user/60331/doc is symbolic link refers to /run/flatpak/doc.

Therefore, I now suspect XDG Desktop Portal wouldn't implement flock operation yet if the error message is correct.

Current versions in my Arch Linux box:

• flatpak 1:1.15.8-1
• xdg-desktop-portal 1.18.4-1
• xdg-desktop-portal-gnome 46.1-1

@kisak-valve

I'm not sure whether it will be merged or not, I created a PR to xdg-desktop-portal repository to merge a patch that is to fix this issue.
https://github.com/flatpak/xdg-desktop-portal/pull/1353

But, the patch would add only non-blocking operations of flock(2) because blocking ops could block entire xdg-document-portal filesystem.

I have a question: Steam client might involve flock(2) with blocking operation?

For now, Steam works well with an external drive.

I also have this issue on Fedora 40, Gnome 46, steam version: 1718904662

Stream is installed via flatpak. I want to install a game on a separate SSD. I try to give the permission using flatsteal, using the filesystem section, as mentioned in the issue. Steam is able to write some folder and file in this directory, but as soon as i start to install the game, it give me the error.

It wasn't clear what the workaround was in https://github.com/ValveSoftware/steam-for-linux/issues/9776
but I was able to workaround it with flatpak override --user com.valvesoftware.Steam --filesystem=/var/mnt/games and I'm able to install games to a second drive mount. I needed to exit out of steam and start it again after setting that override. I'm also running a FC40 based OS.

I personally could install my game with KDE, so I think it's a gnome specific issue

I am having this exact same issue on Fedora 40 Sway edition. I hope your fix can eventually make its way downstream so I can download it on Fedora.

When I unmounted /run/user/$something/doc, the updates where successful. At least I consider this now a workaround. It would be nice if the flock patch would be accepted.

EDIT: it only works, if I first replace the xdg-portal-document process with the one of the proposed PR, then forcefully unmount the FS as root. It is very strange...

I personally had an issue where I had this error (found it with strace) when I tried making a second library in Steam.
flock /run/user/1000/doc/bca8fd30/Steam/steamapps/downloading/state_736260_736263.patch LOCK_SH failed. errno = 38
It would make the second library, drop files in there, but got a disk write error when it came to download and write the game files.
I gave it sufficient permissions in Flatseal, and this was evident because it was creating files in the target library folder.
The issue was that without the permissions, it wanted to use the portal, but the portal doesn't like flock. And even though I gave it permissions after, Steam was still trying to write to the portal while using the unsupported flock.
This was resolved by deleting the library in Steam and recreating it.
I suppose the reason why Steam was able to make the other files was because it didn't use flock while writing them.

tl;dr
Make sure Steam's writing files at all to the folder, if it isn't making any files then give it permissions in Flatseal, if it is creating files but also then giving you a disk write error, then re-creating the library in Steam may fix it.

Thanks, guys :)

tl;dr Make sure Steam's writing files at all to the folder, if it isn't making any files then give it permissions in Flatseal, if it is creating files but also then giving you a disk write error, then re-creating the library in Steam may fix it.

Thanks, guys :)

I gave the permissions to the drive like this:
flatpak override --user --filesystem='/media/my-username/SSD-drive' com.valvesoftware.Steam
As I always found Flatseal and KDE's control panel page confusing for this task.
For some reason it didn't work until I saw your comment and decided to delete the folder, in which I want the library to be and recreate it again and then re-create the library to it in Steam.
Now it works, thanks to your very useful comment!

Just so you know the Steam flatpak added a workaround for this by allowing full permission on all external and secondary disks.

This makes it work for now without doing the flatpak override.

However be aware that this massively breaks security as Steam (and any game and malware installed by it) can now do anything on your disks.
Since it is fairly common to have backups of you private files on secondary disks this can be somewhat similar to malware now having full access to your home directory and being able to steal SSH keys for example as well as infect other files in you backups which makes it easy for the malware to spread.

I hope this can be fixed soon but we have to wait for this:
https://github.com/flatpak/xdg-desktop-portal/issues/1951

Very good points!
I think the best security would be to give per folder permissions and even there to be able to restrict it even more by setting it read-only when we are sure there is not need to modify or create new things.
But since it's hard to guarantee that these things are possible and when they are, that indeed nothing can escape the constraints, I started moving personal file outside of the home directory.
I don't have any SSH keys, but if I'll ever do, I am wondering what can be done to protect those and make the config still work.
Maybe move the config to partition that must be mounted and then put a symlink in it's original location so that everytime the symlink must work, the partion must be mounted and a passwork is required.