You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The permission store should keep permissions of opened (persistent) document. For instance, a recently opened file should be available after several reboots if it has not been deleted (and, of course, if the app asked the permission to be persistent).
Current Behavior
The permission store, according to this page, uses the device id st_dev to store permissions. However, with btrfs (or, I was told, ext4+lvm), the device id is virtual and may not persist with reboots (especially, for instance, in fedora silverblue when an upgrade is carried out).
As a result, permissions are not really persistent and, for instance with Secrets [1], new permissions may be necessary:
And something looks definitively wrong in the exposed filesystem:
[📦 org.gnome.World.Secrets ~]$ ls /var/run/user/1000/doc/*
/var/run/user/1000/doc/33679dc0:
'test.kdbx'
/var/run/user/1000/doc/74ae3507:
'test.kdbx'
/var/run/user/1000/doc/76a9a32b:
'test.kdbx'
/var/run/user/1000/doc/c4a70ceb:
[📦 org.gnome.World.Secrets ~]$ ls /var/run/user/1000/doc/*/*
ls: impossible d'accéder à '/var/run/user/1000/doc/33679dc0/test.kdbx': Aucun fichier ou dossier de ce type # Meaning no such file or directory
ls: impossible d'accéder à '/var/run/user/1000/doc/76a9a32b/test.kdbx': Aucun fichier ou dossier de ce type
'/var/run/user/1000/doc/74ae3507/test.kdbx'
[📦 org.gnome.World.Secrets ~]$
[1] Issue here. In this case it breaks the "recent files" menu.
Steps to Reproduce
Select a file with a flatpak app from, for instance, a btrfs subvolume
"Wait some time" (i.e. wait for something that may change the device id, I think it happens with a silverblue upgrade+reboot, but it also happens several times a week in a regular Ubuntu install)
The flatpak app does not have access to the file anymore
Anything else we should know?
If my diagnosis is correct, this is probably not trivial to fix. It also happens with network shares mounted via gvfs. Maybe the mount point should be recalled in the permission store?
The text was updated successfully, but these errors were encountered:
Operating System
Ubuntu, Fedora
XDG Desktop Portal version
1.18
XDG Desktop Portal version (Other)
No response
Desktop Environment
GNOME
Desktop Environment (Other)
No response
Expected Behavior
The permission store should keep permissions of opened (persistent) document. For instance, a recently opened file should be available after several reboots if it has not been deleted (and, of course, if the app asked the permission to be persistent).
Current Behavior
The permission store, according to this page, uses the device id
st_dev
to store permissions. However, with btrfs (or, I was told, ext4+lvm), the device id is virtual and may not persist with reboots (especially, for instance, in fedora silverblue when an upgrade is carried out).As a result, permissions are not really persistent and, for instance with Secrets [1], new permissions may be necessary:
(see here for more examples)
And something looks definitively wrong in the exposed filesystem:
[1] Issue here. In this case it breaks the "recent files" menu.
Steps to Reproduce
Anything else we should know?
If my diagnosis is correct, this is probably not trivial to fix. It also happens with network shares mounted via gvfs. Maybe the mount point should be recalled in the permission store?
The text was updated successfully, but these errors were encountered: