Desktop mode won't let me change icons, says no write access to .local

[Sunspark-007]

Your system information

• SteamOS version: 3.6.20

Please describe your issue in as much detail as possible:

In desktop mode in the favourites menu, if one wants to change an icon, it won't save the chosen icon. It pops up an error dialog saying:
"Could not save properties due to insufficient write access to: '/home/deck/.local/share/applications/org.flatpakappname.desktop'."

Steps for reproducing this issue:

1. Right click on an icon in favourites, select edit application, click on an icon, choose an icon, press ok, try to apply it.

I feel that the home folder SHOULD have write access to allow people to change the icons.. why are the .desktop files write protected???

[Pointedstick]

I can reproduce this issue. Here's the problem:

$ ls -la /var/lib/flatpak/app/org.videolan.VLC/current/active/export/share/applications/org.videolan.VLC.desktop
-rwxr-xr-x 1 root root 14998 Mar  3 07:50 /var/lib/flatpak/app/org.videolan.VLC/current/active/export/share/applications/org.videolan.VLC.desktop

The Flatpak got installed as root-owned. Changing the desktop file involves changing the app's .desktop file. There's a check to see if the desktop file is root-owned; if it is, the system makes a copy.

In this case the situation is more subtle: the desktop file itself is not root-owned, but it's a symlink pointing to the file that is root-owned.

As a result, the system mis-detects it as being user-owned, tried to change it directly, and fails.

That's when using the properties dialog; when trying to do the same using KMenuEdit, it instead fails silently.

[olib14]

Can you specify what application you're having this problem with and provide the output of ls -al ~/.local/share/applications?

This is likely (going to be) resolved with https://invent.kde.org/plasma/kmenuedit/-/merge_requests/41, but I'd like to confirm.

[Sunspark-007]

ls -al ~/.local/share/applications

Misleading directory because there is not much in it.

The real problem is everywhere else.

/usr/share/applications everything there is root:root
e.g. -rwxr-xr-x 1 root root 9595 Dec 5 2023 kdesystemsettings.desktop

/var/lib/flatpak/exports/share/applications everything there is root:root
e.g. lrwxrwxrwx 1 root root 89 Mar 7 13:07 org.kde.kcalc.desktop -> ../../../app/org.kde.kcalc/current/active/export/share/applications/org.kde.kcalc.desktop

The items in the launcher menus point directly to those.

[olib14]

When you modify an application launcher, a copy of it is saved to ~/.local/share/applications that overrides the original.

It seems that, via the file properties dialog, where the original being copied was a symlink, it would copy the symlink itself rather than the file referenced, such that it ends up trying to access the symlink and modify the original, which it can't due to permissions.

I've introduced changes into KDE Menu Editor to remove an already existing symlink so that it won't block this. It does not appear to have this flaw that creates symlinks.

If you share the specific application and ls -al ~./local/share/applications I can confirm whether this is what is happening in this case.

[Sunspark-007]

It's every application..

Here is my ~/.local/share/applications folder.. as you can see, it is not much. I have many more apps installed, not sure how this folder gets populated. The only ones that had direct user intervention from me was the screenlocker script, a generated file for an appimage, and kfontview-2 was me testing something using the kde dialogs. So just 3 items. All the rest was generated by other stuff.

(deck@steamdeck applications)$ ls -al
total 112
drwxr-xr-x  2 deck deck 4096 Feb  2 20:31  .
drwxr-xr-x 49 deck deck 4096 Mar 18 14:27  ..
-rwxr-xr-x  1 deck deck  181 Sep 22  2022 'Aperture Desk Job.desktop'
-rw-r--r--  1 deck deck  255 Feb  2 20:31  com.github.ryonakano.pinit.24df469d-3ea5-4aa3-827a-b47e65643e3a.desktop
-rw-r--r--  1 deck deck 1063 Nov 13 11:56  com.google.Chrome.flextop.chrome-agimnkijcaahngcdmfeangaknmldooml-Default.desktop
-rw-r--r--  1 deck deck  449 Aug 24  2024  com.google.Chrome.flextop.chrome-kefjledonklijopmnomlcbpllchaibag-Default.desktop
-rw-r--r--  1 deck deck  447 Sep  3  2024  com.google.Chrome.flextop.chrome-mpnpojknpmmopombnjdcgaaiekajbnjb-Default.desktop
-rwxr-xr-x  1 deck deck  169 Sep 21  2022  Hades.desktop
-rwxr-xr-x  1 deck deck  175 Nov  7  2022 'Hollow Knight.desktop'
-rw-------  1 deck deck  145 Dec  6 01:00  kfontview-2.desktop
-rw-------  1 deck deck  106 Dec  6 00:53  kfontview.desktop
lrwxrwxrwx  1 deck deck   99 Dec 11  2023  org.kde.haruna.desktop -> /var/lib/flatpak/app/org.kde.haruna/current/active/export/share/applications/org.kde.haruna.desktop
lrwxrwxrwx  1 deck deck  105 Dec  6 16:16  org.yuzu_emu.yuzu.desktop -> /var/lib/flatpak/app/org.yuzu_emu.yuzu/current/active/export/share/applications/org.yuzu_emu.yuzu.desktop
-rwxr--r--  1 deck deck  242 Dec 16 22:36  screenlock.desktop
-rwxr--r--  1 deck deck 7665 Feb 13  2024  steam.desktop
-rwxr-xr-x  1 deck deck  186 Jul  6  2022 'The Witcher 3 Wild Hunt.desktop'
-rw-r--r--  1 deck deck  259 Feb 13  2023  wine-extension-chm.desktop
-rw-r--r--  1 deck deck  261 Feb 13  2023  wine-extension-hlp.desktop
-rw-r--r--  1 deck deck  259 Feb 13  2023  wine-extension-htm.desktop
-rw-r--r--  1 deck deck  273 Feb 13  2023  wine-extension-ini.desktop
-rw-r--r--  1 deck deck  282 Feb 13  2023  wine-extension-msp.desktop
-rw-r--r--  1 deck deck  264 Feb 13  2023  wine-extension-pdf.desktop
-rw-r--r--  1 deck deck  256 Feb 13  2023  wine-extension-rtf.desktop
-rw-r--r--  1 deck deck  251 Feb 13  2023  wine-extension-txt.desktop
-rw-r--r--  1 deck deck  254 Feb 13  2023  wine-extension-vbs.desktop
-rw-r--r--  1 deck deck  262 Feb 13  2023  wine-extension-wri.desktop
-rw-r--r--  1 deck deck  264 Feb 13  2023  wine-extension-xml.desktop
(deck@steamdeck applications)$ 

[olib14]

And you see this problem happen with Haruna and Yuzu? If so, then it should be fixed in KDE Plasma 6.4 with KMenuEdit.

I'm also looking into the file properties dialog to see if anything needs changing & backporting there.

[Sunspark-007]

Yes.. problem exists with Haruna too.. here is a screencapture where I put a different icon in and pressed ok.

[olib14]

You should be able to work around this for now by using KDE Menu Editor (kmenuedit), after deleting the symlinks manually — I don't believe it ever erroneously made symlinks, but would get stuck on them. I'm not certain if SteamOS ships it.

[Sunspark-007]

It doesn't ship it. Those two in the folder were both installed by Discover app (which is included by SteamOS).

Ugh.. Plasma 6.4 is probably a year away.. SteamOS 3.7 (guessing June stable channel) is only going to be 6.2.5.

Icon packs run in SU mode so they can change a bunch of icons at once so that's nice.

But yeah, looks like SU mode is the order of the day if someone wants to edit the menu entries because of where they point to, using VLC as an example which was also installed using Discover (though it didn't make a link in that .local folder).

Menu editor:

Edit application: