Reported Free Storage for Drive Letter V: is Wrong

[RayJW]

As described in #232, GE-Proton now creates drives from U: upwards, depending on the various mount paths it can find on the system. I can confirm this behaviour because every time I remove the letters V: and X: with Wine configuration, they reappear on relaunch.

However, in my case, it seems like some are still mounted as read-only. I'm using Lutris with GE-Proton 25 (the latest available in Lutris) and this issue happens with 2 different, newly created prefixes for both Ubisoft Connect and the EA App. Once I'm trying to install anything, they report the drives as only having 16 GBs of storage (which obviously isn't the case). They report storage fine for drive letter C: & X:, but the same issue happens with drive Z: (as intended).

Did I misunderstand something, and it's supposed to work like that? In that case, I suppose the idea is for me to manually add another drive letter with these mount points for every prefix?

[RayJW]

The problem seems to be, that /run/media/user is not owned by the user but rather root. Because of that, the available storage reported is wrong. IMHO that is unintended behaviour of umu as the user has full access to /run/media/user/drive. However, since that isn't the case for /run/media wine sees the mount point V: as only 16 GBs of free storage, like with read only mounts, even though the drive is not actually read only. This breaks a good amount of game installs, especially these days, where modern games smaller than 16 GB are rare.

[R1kaB3rN]

The container framework only exposes a subset of the hosts' filesystem paths to its container. This is mentioned a bit in our project's wiki. /run/media happens to be one of those paths that is exposed to the container. For more details on all of the filesystem paths that are exposed by pressure-vessel, see https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/shared-paths.md#introduction.

For further inspection and debugging, you can trying running an interactive shell in the container and setting some environment variables. See https://github.com/Open-Wine-Components/umu-launcher?tab=readme-ov-file#development-and-debugging for more details.

Though, I'd be interested to know if mounting the drive as read-write by setting PRESSURE_VESSEL_FILESYSTEMS_RW solves the issue for you.

[RayJW]

The container framework only exposes a subset of the hosts' filesystem paths to its container. This is mentioned a bit in our project's wiki. /run/media happens to be one of those paths that is exposed to the container. For more details on all of the filesystem paths that are exposed by pressure-vessel, see gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/shared-paths.md#introduction.

Does that mean this behaviour is expected?

Though, I'd be interested to know if mounting the drive as read-write by setting PRESSURE_VESSEL_FILESYSTEMS_RW solves the issue for you.

I tried setting PRESSURE_VESSEL_FILESYSTEMS_RW=/run/media, PRESSURE_VESSEL_FILESYSTEMS_RW=/run/media/user, and PRESSURE_VESSEL_FILESYSTEMS_RW=/run/media/user/drive none of which seems to fix the problem. All with the new umu version 1.2.6 and GE-Proton 9.26, the drives still only show 16 GB of free storage. I'll do some more debugging with logs later.