Accessing External storage from Flatpak apps

[bastianilso]

Living my life as a end-user of flatpak apps, I've come across several apps which would load/scan data from external storage, but not be able to do so given the Flatpak sandbox. Fx:

• Can't use external hard disk as Media Source flathub/tv.kodi.Kodi#46
  "Can't use external hard disk as Media Source"

• VLC can't play from external hard drive flathub/org.videolan.VLC#8
  " VLC can't play from external hard drive"

• Can't add external Steam libraries flathub/com.valvesoftware.Steam#55
  Can't add external Steam libraries

What's the correct way to address these use cases? Do each of those applications need to implement the native file portal (even if some of them (e.g. Kodi) are full screen apps and don't make use of native dialogs)? is there a general permissions setting that could be used to allow those application to access external storage in general?

[TingPing]

Kodi:

They hardcode a list:

  - --filesystem=/mnt
  - --filesystem=/media
  - --filesystem=/run/media

So yea you have to manually extend that if you want more.

VLC:

It has full disk access: "--filesystem=host",

Sounds like a VLC or Qt bug.

Steam:

It purposefully avoids most drive access. You'll just have to manually add them.

---

You add permissions with flatpak override --user --filesystem=/path/to/dir org.app.Id

[bastianilso]

Thanks for the clarification. From a UX POV, this is of course not ideal - we are essentially letting a technical security detail bubble up to the surface and become a barrier to usage .

• If the app was installed with Software there is no part of the flatpak installation process where it becomes clear that the app is imposed these restrictions (and there is no ability to remove them).

• There is currently no way we can understand the intent to access external drives at runtime either, since the external drives are not remotely present in the filesystem which the application can see for security reasons.

The lack of feedback means also that the user could equally blame the software itself for being buggy. The workaround requires familiarization with CLIs and understanding how external storage mounts on your filesystem which might differ depending on the distro.

[TingPing]

• If the app was installed with Software there is no part of the flatpak installation process where it becomes clear that the app is imposed these restrictions (and there is no ability to remove them).

I believe GNOME-Software 3.32 show this. But modifications are done by hand still.

Anyway the long term goal is nothing ever has permissions like that and just works. See GNOME-MPV for an example of a media player with no disk permissions but will work fine.

[gppixelworks]

Thanks for the clarification. From a UX POV, this is of course not ideal - we are essentially letting a technical security detail bubble up to the surface and become a barrier to usage .

The lack of feedback means also that the user could equally blame the software itself for being buggy. The workaround requires familiarization with CLIs and understanding how external storage mounts on your filesystem which might differ depending on the distro.

Blaming, if you will, the software which was installed via Flatpak is, in my view, the outcome for 99% of users.

I've personally experienced the problems of being unable to access drives and directories with:

SchildiChat, a Matrix client

When attempting to upload a file, the selection of directories is severely limited. There was no obvious (or obscure) indication of why.

In most cases I'd have abandoned the software after a poke around and installed something else. I didn't simply because SchildiChat was, in my experience using it as an Android app, superior for my needs to the other Matrix clients.

Posting this problem in the SchildiChat Matrix room I was made aware of up to date .deb packages available from the author's repository. Installation of the .deb package solved the 'problem'.

Being so pleased with the desktop version of SchildiChat, I wanted to see if the problem of severely limited disk drive/directory browsing could be tracked down.

As has been discussed here it was a Flatpak security feature which caused an end user problem. The chat room discussion suggested using Flatseal to edit permissions via it's GUI which solved the problem.

[yhojann-cl]

Same problem (flatpak 1.12.4) using com.valvesoftware.Steam ( flathub/com.valvesoftware.Steam#55 ), games are in external disk, have 4tb of space but my internal disk is a 250gb ssd only. Can not load the steam library using Add steam library folder option from steam, /mnt folder is not visible and can not access to symbolic link from other folders. Same problem using org.gnome.Music, the experience for end user is bad if can not access to external disks.

[kparal]

Just a note, a bit more user friendly than the CLI approach already mentioned is to install Flatseal, select the desired application, and under Filesystem -> Other files specify the path you want to share with it. (Of course, this is still far from the ideal state).

[nickurak]

Is there a high-level design for how this is desired to work?

I was running into this when opening files in /tmp/ or in /mnt/<my drive> with a flatpak app on the command line, and naturally it said "file not found" because it couldn't see the directory (let alone the file) existing.

(I, too, went with flatseal to add access, which worked great as a workaround!)

If an app tries to read something it doesn't have access to, should there be any kind of interactive process whereby a user can indicate that the app should have access to those things? (along the lines of how Android apps prompt for filesystem, camera, or location access when the access is attempted).

Notably that doesn't cover the "I'm want to browse to something that doesn't exist because i can't access it" part, because there'd never be a trigger for accessing something that it can't see yet.

[lospala]

I have installed Ubuntu using a partition for the filesystem and a partition for home.
flatpak does not recognize nothing located outside home partition (in my sda is sda1) . I cannot access to filesystem and media folder where I have mounted two external HDD. filesystem is in sda2
I have tried to give permissions with flatseal but flatseal has no button to save settings so upon exit everyting goes to the default settings.
The only way I can access directly to the entire filesystem is to launch flatpak application from a terminal as root. Otherwise it is impossible so far to access a file outside the first partition of the hdd (in my case home)

[TingPing]

@nickurak I think this idea is technically not reasonable. Unlike Android Flatpak runs regular Linux software as-is. The idea of "just asking" on every open() linux syscall is crazy and can't even know what you intend. Like your /tmp example calling open() there works fine, its just not the /tmp you expected and nothing has a way to know otherwise.

So software must adapt to flatpak, change its open dialogs to use portals, and then things just work. But legacy software will always have a rough UX.

[articpinecone]

I tried using flatseal to give a flatpak program access to a folder stored on a mounted secondary internal drive but it didn't work.

[LuigiWriter]

This may be related or not to your present discussion, however the problem of access has now expanded to
/ and ~/home/
[Bug]: Accessing Internal Storage from Flatpak Apps #4985
I have listed these apps which I have had to uninstall then replace with Ubuntu Software non flatpak versions to make them usable.

From GThumb, the only directory accessible is ~/Pictures. No other directories in home are shown.
GTG 0.6 cannot access ~/.var/app/org.gnome.GTG/data/gtg/ insteads shows a static task list.
Dolphin lists some files and directories but not others which are listed in Nautilus.
A Dolphin baloo search returns "file or folder does not exist." for files and folders which are shown in Nautilus

[CaptainMorgan12]

@TingPing you are awesome that is the only thing that worked:

sudo flatpak override dev.tchx84.Portfolio --filesystem=host

finally shows the /mnt directory with an SD Card. The other commands to that directory ...'/mnt/SDCard' did not work. Now Portfolio a File Manager, finally shows all the files and folders.

Programatically it would be nice if Flatpak simply showed a popup as in:

"Portfolio wants access to your file system: Allow / Deny" Enter sudo password.

[RocketHog55]

It would seem the solution is to simply have external storage be visible to Flatpak apps by default. I saw a stream once of someone talking about how this annoyed them and it was one reason they went back to Windows, clearly this is not good for people staying with Linux. Is this restriction really necessary for "security" reasons in the first place?

[LuigiWriter]

@TingPing I need some clarification about this workaround.

sudo Flatpak override dev.tchx84.Portfolio --filesystem=host

dev.tchx84.Portfolio being the app. 

Sounds like this must be done for each Flatpak app, each session.

If I wanted to run a list of these commands for the Flatpak apps at boot which would be the best file?
I'm a new user on Ubuntu Studio 23.04 and if I remember right there are files that will affect every boot, and ones that only affect the particular session.

And of course, is getting Flatpak access to my external USB drive this way a good or bad idea?

[Ryder17z]

Possible workaround: symlink real directory to some place flatpak can actually access by default?

Not sure if possible or how. but maybe it would suffice in some cases?

[TingPing]

@Ryder17z symlinks don't bypass any permissions, that would be pretty broken.

@RocketHog55 The FileChooser portal is like 8 years old and many projects use it.

@LuigiWriter Giving all of host access isn't ideal. You should give it the single path you care about (--filesystem=/mnt/Whatever). The permissions are persistent you only need to set it once.

[Ryder17z]

@Ryder17z symlinks don't bypass any permissions, that would be pretty broken.

No? Inheritance should solve such. If not, there is the manual option to alter permissions for a folder.

[TingPing]

Anyway I'm closing this as it was really just an old question.

We do have a solution for any file access, its the file chooser portal, many apps use it and they all should.

The first comment documents how to set manual permissions for those that don't.

[Be-ing]

@nickurak I think this idea is technically not reasonable. Unlike Android Flatpak runs regular Linux software as-is. The idea of "just asking" on every open() linux syscall is crazy and can't even know what you intend. Like your /tmp example calling open() there works fine, its just not the /tmp you expected and nothing has a way to know otherwise.

So software must adapt to flatpak, change its open dialogs to use portals, and then things just work. But legacy software will always have a rough UX.

I think @nickurak's idea would be the best solution and closing this issue was premature. Some software has a GUI that shows removable drives separately as removable drives. The file picker portal is not a solution here because it treats all files anywhere on the filesystem as identical, which doesn't allow creating GUIs particular to removable drives. Here is an example from Mixxx, which doesn't work in a Flatpak:

There should either be a Flatpak permission specifically for removable drive access or a portal that an application can use to request permission to access them. Otherwise the application has no way to determine whether a removable device is even available to request access to, so the GUI just shows nothing.

For reference, here is the relevant code in Mixxx: https://github.com/mixxxdj/mixxx/blob/d21cb08ce34904192ffd66a855e90da803949664/src/library/browse/browsefeature.cpp#L341-L361

[TingPing]

The file picker portal is not a solution here because it treats all files anywhere on the filesystem as identical, which doesn't allow creating GUIs particular to removable drives.

I suggest you start a discussion here: https://github.com/flatpak/xdg-desktop-portal/discussions/categories/new-portals

A portal that monitors external drives being attached and notifies/grants access to an application makes sense to me. If I understand your needs.