I installed GIMP via App Center and tried to open files which are clearly marked for [user] in Files, and can be opened with other apps. GIMP ran fine on Ubuntu 20.04 with a similar setup of files on other mounted devices, now that I’ve upgraded, GIMP is presenting issues.
This path is to an SSD other than my system disk:
This path is to a USB drive other than my system disk which is symlinked as “Pictures”:
Files shows that the current [user] “david” has permission to read/write the files under group and user:
BUT… when I dragged the files into my “Pictures_old” dir on the system disk, these images opened as expected.
I tried uninstalling GIMP (snap) and reinstalling it as snap through Apps Center, same issue.
Looking up GIMP issues at GIMP forums, similar issue was solved by installing GIMP via flatpak… so I chased that down for an hour, same issue. GIMP won’t open files clearly assigned to “me”.
I’ve seen how to manage file permissions, but I have no idea how to manage app or program permissions. Has anyone seen this issue with GIMP?
I suspect there are permissions associated with the app or program somewhere… how are these permissions managed?
Thanks @1fallen … for those that follow, here’s what was done:
$ flatpak list (info not in columns to fit)
Name-Application ID-Version-Branch-Installation
GNU Image Manipulation Program org.gimp.GIMP 2.10.38 stable system
$ flatpak uninstall org.gimp.GIMP
ID Branch Op
[-] org.gimp.GIMP stable r
NOTE: Flatpak is expecting the “Application ID” not the NAME in the first column
Uninstall complete.
AND… here’s what “$ sudo apt install gimp” nets…
GIMP is installed as deb… the same issues persist, the same error messages trying to access my files on my own system resources.
Next idea?
CURIOUS: Since Linux thankfully works unlike Windows (sorry, full body shudder commencing…), does restarting the system have any effect with installs / system changes?
linux is not not very intuitive I give you that…but with time you might grow to love it.
I may have to reread your thread.
This is accessed on a ZFS storage drive “tank”
Sorry, this mere mortal makes no sense of most of what you posted.
I only know that I have /mnt and /media devices properly assigned to the OS, can access resources on those devices, except for GIMP… and I have no idea why.
At “sometimes yes…” I restarted the system… partly out of my own curiosity. The restart had no affect as the problem persisted yesterday. Today, at reboot from a cold power-off state, I decided to address the work by moving files to the system disk, dealing with them there, then moving them back (a pain in the butt and waste of time)… but without other solution, the option which remained in order to produce work for a client.
Continuing to troubleshoot I looked at GIMP program again, tried to open files from mounted sources other than my system disk, and they opened.
I don’t get the connection…
AND… with the trouble shooting yesterday among snap install, flatpack install, and deb install, I now have TWO (2) GIMP apps listed in my App Center.
So, that question is a new problem, and likely destined for another post… but perhaps having snap, flatpak, and deb installs place files for the app in different areas of the / (root) system, and that’s where the conflict arose?
NEW QUESTION:
How do I figure out: [1] where these are installed and [2] which of the two is working as expected?
Your issue with snaps isn’t actually an issue with snaps
Snap packages use the apparmor kernel feature to control access to files …
apparmor controls each and every file access in that case (on linux everything is a file … i.e. even your hardware devices are accessed as files in /dev or /sys)
To guarantee full security apparmor refuses to follow any symlinks (it can not really verify the security level of the target of such a link), this is why the gimp from the app center (i.e. the snap) will not be able to access your files that are living in directories you symlinked to other places … since this is a kernel-level limitation, you will see this problem with all snaps you install …
The proper solution would be to use bind-mounts instead of symlinks for your ~/Documents etc, on that level the kernel and apparmor will be able to verify the security integrity of the target filesystem.
Well, that’s the question at hand, and the present hole in my comprehension of the Linux system…
So, the “apparmor kernel” places and controls ALL the app installed files… so there is no scenario where they would be overlapping by being installed in different places ? ? ? ?
That sounds reasonable, only that’s not what is presently happening. Even during the original issue I could access files on those resources and devices… GIMP was the only stubborn app. ALSO, I booted this morning and one of the two GIMP apps which appear to be installed DOES access the files this morning… so, the original problem seems solved… It doesn’t seem to be a kernal “problem” nor any expected and designed function of security as that evidence seems inconsistent… GIMP now accesses other devices, and other programs accessed other devices all along.
YET I’m presented with a new problem, perhaps related, perhaps not: There seem to be two (2) copies of GIMP installed and showing up in the App Center…
Any ideas how to verify the installs and see if there are two running?
No, the apparmor feature of the kernel only controls file access for applications that have been specifically set up to use it, which means a few Deb packaged applications and all snap packaged ones (in snaps apparmor is a mandatory part of the security model, in other package formats it is not)
The app center can manage snaps and Deb packages, if you see the app installed twice you likely have both variants installed and should remove one of them, you can verify the snap install in a terminal with the snap list command (and remove it with snap remove)
The point I was trying to make though is that there are quite a few apps in the default install nowadays that come as snaps (the browser, the default mail client etc) and they will all have the issue that they will not be able to access your symlinked directories due to the apparmor limitation, you should either switch from symlinks to bind-mounts or switch to (likely unsupported) alternatives for these apps
Thank you @tea-for-one… Again, for hurdle after hurdle, I’m amazed at how well conceived and effective this Linux OS environment is when you know the system and how to run it.
The info commands recommended return these items (among much more info for each):
the apt query also includes this message:
“To open files remotely (like over HTTP), install the gvfs-backends package.”
Would “remotely” include “other than the system drive” as remote devices?
After “$ sudo snap disable gimp”, with the GIMP provided by SnapCrafters disabled (the snap package), the remaining GIMP (deb) still available in Apps Center continues to have problems accessing files when tested.
I’d like to get rid of that Ubuntu deb package; re-enable the snap package, then test the snap package to ensure that one no longer poses any issue.
It looks like these apt commands might do what I have in mind (reference URL): $ sudo apt purge gimp (?)
$ apt autoremove (for any remaining unseen dependencies?) and that will address the deb and leave the snap package installed ?
Thanks again… problem addressed, solution targeted… I just have to figure out how to remove that specific deb package. My search for that answer landed me at the solution above… if you’d like to comment or shed some light on that process, I won’t mind one bit.
CURIOSITY QUESTION: So are those deb, snap, and flatpak packages actually installed and run from different areas in the / (root) file system? That’s what I had suspected…
Deb => installed in /usr/bin under the user namespace
Snap => installed in /var/lib/snapd/snap and completely separate namespace and ran using the snap binary with apparmor profiles restricting its access in the system
Flatpak => installed in /var/lib/flatpak and ran using bubblewrap and many other techs
This will remove the deb package
Also, have a look at /home/user/.config/GIMP, there may be some user configuration files present.
If it still exists, temporarily move or delete the folder if you wish to start from scratch
I wanted to reply to this right back at the start, but missed the opportunity, and you got a lot of duff steers. Let’s see what we can do to resolve this properly.
Did we establish that /home/david/Pictures/Pictures/ is on an external drive?
Did you install the snap?
If you go to App Centre, do you see “Snapcrafters” as the publisher?
Make sure the GIMP snap is able to access removable-media. Use System Settings → Apps → Scroll down to GIMP → Click it. You should see something like this. Notice the “Read/write files on removable storage devices” is off, turn it on.
