Hi,
Just upgraded to F41 from F40.
When I try to change properties of a desktop icon (be it VM-manager, Thunderbird, Chrome or any other) the system would not let me to save the changes. because:
Could not save properties due to insufficient write access to: ‘/home/fbures/Desktop/virt-manager.desktop’.
And indeed the above location is a link to /usr/share/applications/virt-manager.desktop
Everything in that directory is owned by root:root
Any advice?
Thanks Frank
On Wed, 20 Nov 2024 at 17:04, Frank Bures buresf@gmail.com wrote:
Just upgraded to F41 from F40.
When I try to change properties of a desktop icon (be it VM-manager, Thunderbird, Chrome or any other) the system would not let me to save the changes. because:
Could not save properties due to insufficient write access to: ‘/home/fbures/Desktop/virt-manager.desktop’.
And indeed the above location is a link to /usr/share/applications/virt-manager.desktop
Everything in that directory is owned by root:root
This has been touched on a few times in previous threads, it's always a good idea to check the archives. (Although the hyperkitty search and browsing seems a little broken currently?!)
This article covers .desktop files fairly comprehensively: https://www.baeldung.com/linux/desktop-entry-files
And from an older thread on the Chrome desktop file:
And, just for posterity: https://forums.debian.net/viewtopic.php?t=154052
Note: Please don't modify .desktop files in /usr/share/applications as a)
that would require root and b) your changes will be overwritten the next time the app is updated. If you want to modify a .desktop file copy the file to ~/.local/share/applications and edit it there.
.desktop files in ~/.local/share/applications take precedence over . desktop files with the same name in /usr/share/applications and you can hack up the ones in your home directory all day long - worst that could happen is you'd do it wrong and have to start over but the original . desktop file is still on your system :)
On 2024-11-20 12:20, Will McDonald wrote:
On Wed, 20 Nov 2024 at 17:04, Frank Bures <buresf@gmail.com mailto:buresf@gmail.com> wrote:
Just upgraded to F41 from F40. When I try to change properties of a desktop icon (be it VM-manager, Thunderbird, Chrome or any other) the system would not let me to save the changes. because: Could not save properties due to insufficient write access to: ‘/home/fbures/Desktop/virt-manager.desktop’. And indeed the above location is a link to /usr/share/applications/virt-manager.desktop Everything in that directory is owned by root:rootThis has been touched on a few times in previous threads, it's always a good idea to check the archives. (Although the hyperkitty search and browsing seems a little broken currently?!)
This article covers .desktop files fairly comprehensively: https://www.baeldung.com/linux/desktop-entry-files <https:// www.baeldung.com/linux/desktop-entry-files>
Thanks, but this is not what I had in mind.
I was talking about right-clicking an icon on the desktop, clicking Properties and then trying to save the change by clicking OK. That's when the error message is generated.
I believe this should work right-off-the-box, otherwise I do not understand why the Properties item is even in the menu.
Cheers Frank
On 2024-11-20 13:06, Frank Bures wrote:
I was talking about right-clicking an icon on the desktop, clicking Properties and then trying to save the change by clicking OK. That's when the error message is generated.
I believe this should work right-off-the-box, otherwise I do not understand why the Properties item is even in the menu.
This is interesting.
The problem only occurs when the desktop icon is created as a link.
How to reproduce - plasma desktop:
1. Click on Fedora symbol on the task bar. 2. Enter the search string into the search field, i.e. Thunderbird 3. Drug the result (Thundebird) to the desktop. 4. A drop list appears 5. Choose "Link here" 6. Properties of the icon created in such a way cannot be changed
However, if one chooses "Copy here" in 5 above, the properties of the created icon can be changed.
Is that the intentional behaviour?
I do not remember seeing it in F40.
Cheers Frank
On Wed, Nov 20, 2024 at 1:23 PM Frank Bures buresf@gmail.com wrote:
On 2024-11-20 13:06, Frank Bures wrote:
I was talking about right-clicking an icon on the desktop, clicking Properties and then trying to save the change by clicking OK. That's when the error message is generated.
I believe this should work right-off-the-box, otherwise I do not understand why the Properties item is even in the menu.
This is interesting.
The problem only occurs when the desktop icon is created as a link.
How to reproduce - plasma desktop:
- Click on Fedora symbol on the task bar.
- Enter the search string into the search field, i.e. Thunderbird
- Drug the result (Thundebird) to the desktop.
- A drop list appears
- Choose "Link here"
- Properties of the icon created in such a way cannot be changed
However, if one chooses "Copy here" in 5 above, the properties of the created icon can be changed.
Is that the intentional behaviour?
Likely. You user does not have write access to /usr/share, where the desktop icons reside on disk.
$ find /usr/share -name "*.desktop" /usr/share/kinfocenter/categories/lostfoundcategory.desktop /usr/share/kinfocenter/categories/networkinfocategory.desktop /usr/share/kinfocenter/categories/graphicalinfocategory.desktop /usr/share/kinfocenter/categories/deviceinfocategory.desktop /usr/share/kinfocenter/categories/basicinformation.desktop /usr/share/kinfocenter/categories/detailedinformation.desktop ...
I suppose you could modify the source of the link if you used gksudo... but I do what you did -- I copy the icon to my desktop, and modify it at its new home.
In the old days, you also had to chmod +x <package>.desktop. I don't think you need to do it anymore. If you have trouble, then add +x.
I do not remember seeing it in F40.
Jeff
Could this be a task for the handler that tries to modify the file, where it would observe the presence of a link and the lack of RW access, and then remove the link and copy in the right place in ~ ?
The one size fits all might be a good starting point, but doesn't scale ( down) to individual customizations.
On Wed, Nov 20, 2024, 2:02 PM Jeffrey Walton noloader@gmail.com wrote:
On Wed, Nov 20, 2024 at 1:23 PM Frank Bures buresf@gmail.com wrote:
On 2024-11-20 13:06, Frank Bures wrote:
I was talking about right-clicking an icon on the desktop, clicking Properties and then trying to save the change by clicking OK. That's when the error message is generated.
I believe this should work right-off-the-box, otherwise I do not
understand
why the Properties item is even in the menu.
This is interesting.
The problem only occurs when the desktop icon is created as a link.
How to reproduce - plasma desktop:
- Click on Fedora symbol on the task bar.
- Enter the search string into the search field, i.e. Thunderbird
- Drug the result (Thundebird) to the desktop.
- A drop list appears
- Choose "Link here"
- Properties of the icon created in such a way cannot be changed
However, if one chooses "Copy here" in 5 above, the properties of the created icon can be changed.
Is that the intentional behaviour?
Likely. You user does not have write access to /usr/share, where the desktop icons reside on disk.
$ find /usr/share -name "*.desktop" /usr/share/kinfocenter/categories/lostfoundcategory.desktop /usr/share/kinfocenter/categories/networkinfocategory.desktop /usr/share/kinfocenter/categories/graphicalinfocategory.desktop /usr/share/kinfocenter/categories/deviceinfocategory.desktop /usr/share/kinfocenter/categories/basicinformation.desktop /usr/share/kinfocenter/categories/detailedinformation.desktop ...
I suppose you could modify the source of the link if you used gksudo... but I do what you did -- I copy the icon to my desktop, and modify it at its new home.
In the old days, you also had to chmod +x <package>.desktop. I don't think you need to do it anymore. If you have trouble, then add +x.
I do not remember seeing it in F40.
Jeff
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 2024-11-20 10:22, Frank Bures wrote:
On 2024-11-20 13:06, Frank Bures wrote:
I was talking about right-clicking an icon on the desktop, clicking Properties and then trying to save the change by clicking OK. That's when the error message is generated.
I believe this should work right-off-the-box, otherwise I do not understand why the Properties item is even in the menu.
This is interesting.
The problem only occurs when the desktop icon is created as a link.
How to reproduce - plasma desktop:
- Click on Fedora symbol on the task bar.
- Enter the search string into the search field, i.e. Thunderbird
- Drug the result (Thundebird) to the desktop.
- A drop list appears
- Choose "Link here"
- Properties of the icon created in such a way cannot be changed
However, if one chooses "Copy here" in 5 above, the properties of the created icon can be changed.
Is that the intentional behaviour?
Yes, that's intentional. Do you understand what a soft link is? It's pointing to the original file, which is normally what you want. If you want to be able to edit it, then you need to copy it instead, because then you own the file.
On Wed, 2024-11-20 at 13:22 -0500, Frank Bures wrote:
The problem only occurs when the desktop icon is created as a link.
Yes, you had the reason why a link is doing that in a prior message in this thread.
How to reproduce - plasma desktop:
- Click on Fedora symbol on the task bar.
- Enter the search string into the search field, i.e. Thunderbird
- Drug the result (Thundebird) to the desktop.
- A drop list appears
- Choose "Link here"
- Properties of the icon created in such a way cannot be changed
However, if one chooses "Copy here" in 5 above, the properties of the created icon can be changed.
And that explanation covered why you would copy a desktop file, rather than link to it.
Is that the intentional behaviour?
I'd say so. You've been given two choices about what to do with the thing you want to create a short-cut to (copy or link). If you want to modify it in some way, copy it and modify it. If you just want to use it as-is, you can simply link to it. The short-cut creation menu choices has already provided you with what you need.
I think the issue may be that you're used to some old behaviour where you can "create a short-cut" to something, and that shortcut always was simply a copy of the desktop file.
Once more:
A *copy* creates a desktop file in your space that you own, and you can modify. The original desktop launcher file (elsewhere on the system) will not be changed, and will be ignored.
A *link* points to a file somewhere else on the system, and if that somewhere else isn't owned by you (it won't be, in this case), you can't modify it.
On 2024-11-20 22:24, Tim wrote:
Once more:
A *copy* creates a desktop file in your space that you own, and you can modify. The original desktop launcher file (elsewhere on the system) will not be changed, and will be ignored.
A *link* points to a file somewhere else on the system, and if that somewhere else isn't owned by you (it won't be, in this case), you can't modify it.
Thank you all.
Cheers Frank
On 21/11/24 15:32, Frank Bures wrote:
On 2024-11-20 22:24, Tim wrote:
Once more:
A *copy* creates a desktop file in your space that you own, and you can modify. The original desktop launcher file (elsewhere on the system) will not be changed, and will be ignored.
A *link* points to a file somewhere else on the system, and if that somewhere else isn't owned by you (it won't be, in this case), you can't modify it.
Thank you all.
Just a silly question, have you tried playing around with setfacl on the desktop link in your home folder to give your account write access to the file? I do that with my Thunderbird and firefox installations where I have them installed in /opt which is owned by root, so I run setfacl across both of the sub-folders to ensure that configuration changes I do in both actually get retained. I know I could install them in folders I do have access to, I just haven't chosen to do that. Just another silly question, are you running KDE under Wayland or Xorg? I'm asking because experience tells me that Wayland seems to pick and choose what properties exposed by a desktop file on the desktop it is actually going to honour, even when the desktop file is created manually by right clicking on the desktop and selecting "New", which seems to be different to what is does for apps pinned to the task bar where it seems to honour options that it doesn't honour from the file on the desktop. I have this issue with my firefox and Thunderbird icons on the desktop both of which were created in F40 under Xorg. I had to do a lot of playing around with the "launch feedback" setting in the firefox icon to get Wayland to honour the setting, but I've been unable to get Wayland to honour the same setting in the Thunderbird icon.
regards, Steve
Cheers Frank
On 22/11/24 08:57, Stephen Morris wrote:
On 21/11/24 15:32, Frank Bures wrote:
On 2024-11-20 22:24, Tim wrote:
Once more:
A *copy* creates a desktop file in your space that you own, and you can modify. The original desktop launcher file (elsewhere on the system) will not be changed, and will be ignored.
A *link* points to a file somewhere else on the system, and if that somewhere else isn't owned by you (it won't be, in this case), you can't modify it.
Thank you all.
Just a silly question, have you tried playing around with setfacl on the desktop link in your home folder to give your account write access to the file? I do that with my Thunderbird and firefox installations where I have them installed in /opt which is owned by root, so I run setfacl across both of the sub-folders to ensure that configuration changes I do in both actually get retained. I know I could install them in folders I do have access to, I just haven't chosen to do that. Just another silly question, are you running KDE under Wayland or Xorg? I'm asking because experience tells me that Wayland seems to pick and choose what properties exposed by a desktop file on the desktop it is actually going to honour, even when the desktop file is created manually by right clicking on the desktop and selecting "New", which seems to be different to what is does for apps pinned to the task bar where it seems to honour options that it doesn't honour from the file on the desktop. I have this issue with my firefox and Thunderbird icons on the desktop both of which were created in F40 under Xorg. I had to do a lot of playing around with the "launch feedback" setting in the firefox icon to get Wayland to honour the setting, but I've been unable to get Wayland to honour the same setting in the Thunderbird icon.
regards, Steve
Just further to this, on my system if ~/Desktop has a .desktop file in it that is a link to a /usr/share sub-folder, the permissions tab in properties correctly says I don't have access to the file being linked to, but if I change any of the properties and try to save the changes I get an access violation message on ~/Desktop, which is rubbish as the soft link in ~/Desktop is owned by me. The error message should say I don't have access to the file that is linked to.
regards, Steve
Cheers Frank
On Fri, 2024-11-22 at 09:27 +1100, Stephen Morris wrote:
Just further to this, on my system if ~/Desktop has a .desktop file in it that is a link to a /usr/share sub-folder, the permissions tab in properties correctly says I don't have access to the file being linked to, but if I change any of the properties and try to save the changes I get an access violation message on ~/Desktop, which is rubbish as the soft link in ~/Desktop is owned by me. The error message should say I don't have access to the file that is linked to.
That's going to depend on the tool you're using (how well thought out it was). When acting on a link you could either (a) modify the link, (b) follow the link and act on what it points to.
One's quite obvious what to do in some circumstances: I probably want to edit a file I linked to with a text editor. I probably want to see info about a linked file when listing a directory or viewing file permissions.
Other time's less so: I probably want to modify the permissions of a link, but not always.
I'm always a bit dubious about deleting a link. I don't want the tool to delete the file it links to.
On 2024-11-21 23:07, Samuel Sieb wrote:
On 2024-11-21 22:27, Tim via users wrote:
I'm always a bit dubious about deleting a link. I don't want the tool to delete the file it links to.
I've never seen a tool that would do that.
Actually, there's one case to be aware of on the command line. If you have a link to a directory, if you put the "/" on the end, it refers to the target, not the link. But then you should be using just "rm", not "rm -r" anyway, so it would fail if you have the "/".
On 22/11/24 17:27, Tim wrote:
On Fri, 2024-11-22 at 09:27 +1100, Stephen Morris wrote:
Just further to this, on my system if ~/Desktop has a .desktop file in it that is a link to a /usr/share sub-folder, the permissions tab in properties correctly says I don't have access to the file being linked to, but if I change any of the properties and try to save the changes I get an access violation message on ~/Desktop, which is rubbish as the soft link in ~/Desktop is owned by me. The error message should say I don't have access to the file that is linked to.
That's going to depend on the tool you're using (how well thought out it was). When acting on a link you could either (a) modify the link, (b) follow the link and act on what it points to.
One's quite obvious what to do in some circumstances: I probably want to edit a file I linked to with a text editor. I probably want to see info about a linked file when listing a directory or viewing file permissions.
Other time's less so: I probably want to modify the permissions of a link, but not always.
I'm always a bit dubious about deleting a link. I don't want the tool to delete the file it links to.
All I'm doing is right clicking on a desktop icon with the mouse, where the icon is a soft link, that was create by the install of a package from it repository (Google Chrome), selected properties and tried to check the "Launch Feedback" option, and the click "OK", and it displays a message that the action failed on the file in ~/Desktop, which is wrong as I own them all.
regards, Steve
On Sat, 2024-11-23 at 10:15 +1100, Stephen Morris wrote:
All I'm doing is right clicking on a desktop icon with the mouse, where the icon is a soft link, that was create by the install of a package from it repository (Google Chrome), selected properties and tried to check the "Launch Feedback" option, and the click "OK", and it displays a message that the action failed on the file in ~/Desktop, which is wrong as I own them all.
Where does that icon's link point to?
Usually these things are not installed to somewhere inside the user's homespace, even if a launch file is. And those installed files are usually not owned by the user either (it's a security/safety risk).
On 23/11/24 16:20, Tim wrote:
On Sat, 2024-11-23 at 10:15 +1100, Stephen Morris wrote:
All I'm doing is right clicking on a desktop icon with the mouse, where the icon is a soft link, that was create by the install of a package from it repository (Google Chrome), selected properties and tried to check the "Launch Feedback" option, and the click "OK", and it displays a message that the action failed on the file in ~/Desktop, which is wrong as I own them all.
Where does that icon's link point to?
Usually these things are not installed to somewhere inside the user's homespace, even if a launch file is. And those installed files are usually not owned by the user either (it's a security/safety risk).
In the case of the Google Chrome soft link in ~/Desktop it is pointing to /usr/share/applications/google-chrome.desktop. Other than the icon for eclipse which is a softlink to /home/steve/.local/share/applications/epp.package.committers.desktop the chrome icon is the only softlink on the desktop. The other icons were created by me by right clicking on the desktop and select "Create New->Link to Application" which has created the .desktop files in ~/Desktop which aren't softlinks.
regards, Steve
On 24/11/24 10:38, Stephen Morris wrote:
On 23/11/24 16:20, Tim wrote:
On Sat, 2024-11-23 at 10:15 +1100, Stephen Morris wrote:
All I'm doing is right clicking on a desktop icon with the mouse, where the icon is a soft link, that was create by the install of a package from it repository (Google Chrome), selected properties and tried to check the "Launch Feedback" option, and the click "OK", and it displays a message that the action failed on the file in ~/Desktop, which is wrong as I own them all.
Where does that icon's link point to?
Usually these things are not installed to somewhere inside the user's homespace, even if a launch file is. And those installed files are usually not owned by the user either (it's a security/safety risk).
In the case of the Google Chrome soft link in ~/Desktop it is pointing to /usr/share/applications/google-chrome.desktop. Other than the icon for eclipse which is a softlink to /home/steve/.local/share/applications/epp.package.committers.desktop the chrome icon is the only softlink on the desktop. The other icons were created by me by right clicking on the desktop and select "Create New->Link to Application" which has created the .desktop files in ~/Desktop which aren't softlinks.
I've done some further checking on this and it may be that the install of Google-Chrome didn't put a softlink in ~/Desktop. With the Google-Chrome.desktop file still in ~/Desktop, I've clicked on the KDE throbber and dragged the Google Chrome entry to the desktop which has then prompted for "Copy Here", "Link Here" or "Widget->Add Icon". If I select "Link Here" it pops up a dialogue box asking me to change the name of the .desktop file as doing the copy was going to overwrite /usr/share/applications/google-chrome.desktop with itself, so I may have originally created the softlink by doing that after installing Google-Chrome from its repository.
regards, Steve
regards, Steve
-
Frank Bures -
Jeffrey Walton -
John Westerdale -
Samuel Sieb -
Stephen Morris -
Tim -
Will McDonald