Bug 394476 - Can't edit applications that are installed through flatpak
Summary: Can't edit applications that are installed through flatpak
Status: CONFIRMED
Alias: None
Product: kmenuedit
Classification: Applications
Component: general (show other bugs)
Version: 5.23.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 443477 466875 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-05-20 14:17 UTC by Peter Eszlari
Modified: 2024-11-01 17:00 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
screenshot (313.45 KB, image/png)
2018-09-07 15:12 UTC, Patrick Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Eszlari 2018-05-20 14:17:46 UTC
When I try to edit an application entry in the start menu (Kicker) by right clicking ("Edit Application...") that belongs to a flatpak app, I get the error message:

"Could not save properties. You do not have sufficient access to write to /home/peter/.local/share/applications/org.example.App.desktop."

If I then look under /home/peter/.local/share/applications, I see a link created to points to

/var/lib/flatpak/app/org.example.App/current/active/export/share/applications/org.example.App.desktop
Comment 1 Patrick Silva 2018-09-07 15:12:04 UTC
Created attachment 114826 [details]
screenshot

Same bug on Arch Linux, plasma 5.13.5.
Comment 2 Nicolas Fella 2019-03-16 15:43:33 UTC
The problem is this:

Editing a .desktop file in /usr/share/applications wouln't work because of insufficient permissions. Therefore when the user tries to edit such a file a copy is created in .local/share/applications that takes precedence over the one in /usr.

Editing a .desktop file in .local/share/applications works and therefore it will be edited directly.
In the flatpak case where .local/share/foo.desktop is a symlink to another desktop file Kicker thinks the desktop file is editable by the user, but the actual symlink target is not (because of insufficient permission) and editing fails
Comment 3 Nate Graham 2021-10-11 16:50:16 UTC
*** Bug 443477 has been marked as a duplicate of this bug. ***
Comment 4 Patrick Silva 2021-10-14 11:59:58 UTC
I can reproduce this bug even with some non-flatpak apps.
Discord from Arch repos, for example.

Operating System: Arch Linux
KDE Plasma Version: 5.23.0
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Graphics Platform: Wayland
Comment 5 Thiago Sueto 2021-11-17 02:54:14 UTC
In the meantime, for those looking for a workaround, you can simply install your flatpak repositories with the --user flag, e.g.

flatpak remote-add --user flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo

This way sudo isn't needed to install applications, they are installed in userspace (~/.local/share/flatpak/exports/share/applications/ would include symlinks to ~/.local/share/flatpak/app/), and editing the .desktop launchers works as intended since there are sufficient permissions.
Comment 6 Roman Nikonov 2022-02-23 00:10:34 UTC
(In reply to Patrick Silva from comment #4)
> I can reproduce this bug even with some non-flatpak apps.
> Discord from Arch repos, for example.

The bug is similar, but, according to the screenshot by Patrick Silva, the source of the problem is different. With Flatpak (current issue), there's already a file at `~/.local/share/applications/whatever.desktop`. The Discord case is a bit different. It has a symlink in system-wide directory instead:
$ ls -lh /usr/share/applications/discord.desktop
lrwxrwxrwx 1 root root 28 фев 18 13:34 /usr/share/applications/discord.desktop -> /opt/discord/discord.desktop

I've created a separate bug for this: https://bugs.kde.org/show_bug.cgi?id=450727
I'll also attach a merge request that potentially fixes this issue there.

P.S. Sorry if I don't understand some concepts of Flatpaks correctly, as I don't actually use them.
Comment 7 Patrick Silva 2023-03-05 18:08:36 UTC
*** Bug 466875 has been marked as a duplicate of this bug. ***
Comment 8 John Kizer 2024-11-01 17:00:05 UTC
In the case of this that I've seen on my PC, there actually is not already a file at ~/.local/share/applications, but the process of trying to edit the application menu item then creates a broken link attempting to reach the target file (in addition to the error already described here):

After trying to edit the menu item:
> johnkizer@g717-fedora:~$ ll .local/share/applications/
> ...
> lrwxrwxrwx. 1 johnkizer johnkizer  119 Nov  1 12:42  org.nickvision.tubeconverter.desktop -> > ../../../app/org.nickvision.tubeconverter/current/active/export/share/applications/org.nickvision.tubeconverter.desktop
> ...

The path shown there, according to the properties dialog, tries to resolve to /home/johnkizer/app/org.nickvision.tubeconverter/current/active/export/share/applications/org.nickvision.tubeconverter.desktop, which doesn't exist - not yet sure what's going on there.