I installed Krita successfully on Ubuntu 22.04 I have a second HDD auto mounted (fstab) at /PHOTOS but krita cannot see it.
When I install Krita with apt the hard drive is visible normally.
I’ve read that this is a security measure, but if so it would be nice if there was a way of circumventing it.
If I’m not mistaken, a Snap app that has the removable-media plug can access HDDs mounted in /media, run/media, and /mnt.
I installed Krita and it has this plug; it even connects automatically.
Thanks… but I’m not talking about removable media. This is an installed second drive with a permanent fstab entry.
“removable-media” is just a name; it doesn’t mean it’s only for USB flash drives, for example.
A bind-mount to an accessible place (e.g. in /media, /run/media, or /mnt with removable-media; or your home directory…) should work as a workaround.
Also note according to its assert file, that the krita snap has automatic r/w access to $HOME/\.local/share/krita, so that may be also worth considering to bind-mount.
But I cant find that when looking into its snapcraft.yaml file, so maybe that does not work.
(Yikes, i had to snap download and unsquashfs to figure all that out; isnt there UI for seeing permissions without installing a snap(?)).
According to the snapcraft yaml it supports the home and removable-media connections; if that is not auto-connected you could add those connection manually.
Rechecking the assert file, ~/.local/share/krita and removable-media are auto-connected, so in your shoes I would mount (or adding a bind-mount) at /mnt/PHOTOS. That does not give extra permissions to the snap and seems okayish.
On the other hand I am bit surprised, I would expect krita to use the file picker portal (where you should be able to any path AFAIK); isnt that so or is it not working with your hdd or is that simply not enough for your use case?
I’ve used an unconventional mount point for the HDD, namely /PHOTOS
I can’t think of any unix reason not to do this and I have lots of mini scripts etc for my setup, which I would have to change.
Can someone tell me where to look … I’ve looked at the Krita snapcraft.yaml and all I can find is
plugs:
- home
- removable-media
- cups
If this is the right place to look, can I specify the whole filesystem, and if so, how? Where would I find the documentation for all the options? I’ve looked at the docs for snapcraft.yaml but there doesn’t seem to be a list of options apart from home and removable-media. It’s a bit opaque.
Any help appreciated… thanks.
I can’t think of any unix reason not to do this and I have lots of mini scripts etc for my setup, which I would have to change.
Just remember this is not “unix” territory, this is “nested operating systems in your host system” or “installing applications from external ecosystems”. So there are valid reasons which are not directly applicable to “normal” unix.
There is no direct support for arbitrary host paths in the snap ecosystem. If you want to see official documentation for a similar case: Home directories outside of '/home' | Snapcraft documentation
What you should not do: It may be possible to circumvent the container/sandbox and there is a chance krita works on your system without any safety or other guarantees.
What you should do - if you want to use the krita snap and keep the data in the /PHOTOS location, use a bind mount so the snap can find it.
It should work like this (if you use /mnt as base);
$ sudo mkdir -p /mnt/PHOTOS
$ sudo mount --bind /PHOTOS /mnt/PHOTOS
bind mount worked. I guess it’s not something I’ve ever need to do before, and to me at least it wasn’t obvious.
thank you
No problem. It is not intuitive/obvious to anyone.
Not sure this is a documentation issue/not sure where I would put documentation for that
Snapd doesn’t have support for arbitrary file access of non-predefined-and-configured paths, you may check out what paths are allowed in the related security confinement interface’s documentation, e.g. The removable-media interface | Snapcraft documentation.
Bind-mounting the unsupported directories is a known workaround of this limitation.
You can’t specify arbitrary paths to bypass the confinement at the moment.
I’ve added a note here: The removable-media interface
I don’t want to quibble, but “removable media” is immediately misleading. I did check that page and it didn’t seem to relate to an installed HDD.
While the bind-mounting works, it certainly isn’t obvious. In over 20 years of using linux I’ve never used a bind mount. I know that only means that my knowledge is imperfect, fair enough, but I’ve auto mounted plenty of drives using fstab and never run into this problem.
What bothers me is that it’s a “security” feature that is pushed onto me whether I like it or not, or even whether I know about it or not. Also, perhaps I’m showing my ignorance but I can’t see where bind-mounting to /mnt is better than simply mounting anywhere else on the file system.
Oh well. Now I know.
I agree, unfortunately there are no mechanisms nor standards to hint snapd the other use cases(e.g. the Unix way) to allow the access.
That’s how it does as a workaround.
It’s part of the characteristics/limitations of snap apps(and any “containerized” software distribution like Flatpak apps/Docker containers). The only way to “opt-out” them is to not installing them in the first place.
I would suggest checking out the following documentation to make your life easier:
What bothers me is that it’s a “security” feature that is pushed onto me whether I like it or not,
For the desktop this is mostly a distribution feature. With containerization it is possible to have a ~current krita on one of the eight(?) ubuntu releases currently maintained. Else you would probably enjoy krita 3.1 on ubuntu downstreaming from debian. Or you would be completely on your own having to compile it.
Having an up-to-date and more secure krita might be nice. But it is essential/more important for browsers which need to be updated frequently because those execute uncontrolled untrusted third party code all the time. (And i think browsers are the only thing which ubuntu OS delivers out of the box as snaps).
If you are installing snaps or flatpaks in the general case you are increasing the attack surface (because it does not get filtered by maintainer and distribution), so it is good to have some damage control by the security features of containerization.
or even whether I know about it or not.
This is definitely an UI issue. One with which all containerization/isolation mechanisms struggle with.
Also, perhaps I’m showing my ignorance but I can’t see where bind-mounting to /mnt is better than simply mounting anywhere else on the file system.
It is a controlled point of entry with broad access to dynamically available resources.
I think there are technical issues with providing access to user-chosen directories on a per-user base, so canonical does not want to go there. The “correct” non-workaround solution is using the xdg-desktop-portal in the application and its snap.
As far as i get it, that should be possible to use actually; although it might need configuration(?); see for reference flatpak/appimage issue https://bugs.kde.org/show_bug.cgi?id=506926
I think you did not answer when I brought the file picker up the first time. Is there any reason why that would not work for your use case?
That’s a good question… probably because I wasn’t sure what you meant by “file picker”. I assumed you were referring to Krita’s normal open file dialogue. Once again, forgive my ignorance. Or do you mean drag and drop from Nautilus.
I’m finding all of this a bit convoluted. I’ve been running linux servers and desktops since 1996 and find it odd that suddenly I’m running into a problem like this. What chance would a newbie have?
Maybe it’s just because I chose to mount an internal drive in slightly unconventionally.
The bind-mount works, but it’s non-trivial, by which I mean it’s not obvious or easily discovered without a technical forum like this. It’s not user-friendly.
In any case, thanks for the discussion.
That’s a good question… probably because I wasn’t sure what you meant by “file picker”. I assumed you were referring to Krita’s normal open file dialogue.
yes, a normal open file dialogue should work with the snap (or flatbox) sandbox. No matter where your stuff is located. If the application (i.e krita/snap+krita) uses the right file picker “protocol”, the open file dialogue gets opened by the desktop and not by krita itself and has full access like your user.
So I assume the normal open file dialogue does not work for you? Please get in touch with the krita folks, because I think krita has support for the open file dialogue via xdg-desktop-portal.
What chance would a newbie have?
A newbie should not run into this problem.