Can't launch untrusted app-launchers (.desktop) in GNOME

Bug #572918 reported by FERNmann on 2010-05-01
This bug affects 17 people
Affects Status Importance Assigned to Milestone
meta-gnome2 (Ubuntu)

Bug Description

Hello Community,

I installed Ubuntu 10.04 Lucid Lynx yesterday and tried to start an application launcher (a .desktop file) which was placed via GeoGebra ( The launcher was in an untrusted state, so you couldn't see the icon. In 9.10, after a double click, a dialog would open where you could mark it as trusted, but in 10.04, a dialog opens also, but the only button available is "Cancel". Check the attached file to see what I mean.

My question is: Is this a bug, so in can be fixed, or a even feature? And what can I do to run untrusted launchers on lucid?

This affects me as well. It's almost impossible to tell the difference between a bug and a feature these days so you did the right thing raising a bug report!

It appears that the developers have been reviewing the actions taken if the "execute bit" isn't set. So you can no longer run programs from a CD or programs marked as untrusted.

The work around for now is to use a terminal, navigate to the folder holding your program, use ls -l to confirm the 'x' bit is not set and then use "chmod +x" to set the bit. The program should run. (It does for me.) This doesn't work for CD's which are read only.

I wouldn't expect a team who ignores all the pleas not to move the maximize, minimize, close buttons to the left will care if we don't like this feature/bug so I wouldn't hold your breath waiting for a solution. Fortunately there are enough people out there who like Ubuntu enough to search for work-arounds for the unexplained vagaries of the developers so google your feature-bugs to find a fix.

One day Linus Torvalds said something about "interface-nazis" - he could be right...

Dan (dan-zachary) wrote :

I have the same problem. Looks like two buttons are missing in 10.4.

Here is a work around. Clumsy, but it works.

The permissions on the file after down load are 1140 -rwxr-xr-x file.desktop

If I run sudo chmod ugo+rx *.desktop

Now, the permissions are STILL 1140 -rwxr-xr-x file.desktop

But now the file is now executable from the desktop. Strange that I can't see a change in permissions, but running this command seems to make a difference.

Same here,

$ ls -al

shows me the execute bit is set, but if I type

$ chmod +x *.desktop

I can run the launcher. This also works if I uncheck and recheck the execute box in Nautilus.

Stuart Vickers (sv87411) wrote :

I experience this too and I was surprised not to see the 'Mark as trusted' option that was in 9.10.

Whether this is a regression bug where functionality has been affected by a change elsewhere or whether this is functionality by design is not clear.

What is clear is that to a standard user the error text "The application launcher "xxxx.desktop" has not been mark as trusted. If you do not know the source of this file, launching it may be unsafe" is of no use whatsoever. And offering cancel as the only selection to proceed with no guidance on how to rectify the problem is even less useful. The average user will right click the icon and look for and option like "Mark as trusted". Even if the do look at the permissions tab in file properties, there is no correlation between "Allow executing file as a program" and "Mark as trusted". The hope is the user will make this correlation or make a lucky guess and select this option without being sure of the real consequences.

Since when did a file with the execute bit set become known as a "trusted file", did I miss a memo? In fact trusted/untrusted aren't standard Linux file permissions aer they and so this wording is misleading at best. Especially when a simple Google search for "how to mark file as trusted in ubuntu" results in pages describing this bug and no "how-tos" on how to make a file trusted. It's bad terminology.

At least if the "Mark as trusted" option were retained users who do know the source of the launcher would have an easy mechanism to be able to execute it without resorting to a Google search and looking through a bug report for command line based workarounds.

As such I believe this sits firmly in regression bug territory, if only because there is no mechanism for making a launcher trusted provided in the pop-up window or even described in the error text.

I can only assume this behaviour has been implemented by a developer (not necessarily an Ubuntu dev) used to the nannying ways of Windows where at all times the user needs to be encouraged to be safe, but has erred on the side of "ultra-nanny" whereby no option to 'trust' the launcher is provided and the nanny won't even tell you how to do it via alternative means.

It's disappointing that situations like this are being implemented and/or devs are seeing this as good practice, because its really elementary usability design.

Let's hope "ultra-nanny" isn't part of Ubuntu's re-branding and that this is a simple bug, acknowledged, easily remedied by re-introducing the previous behaviour of the pop-up and users aren't being encouraged to resort to command line based solutions.

Troy (tjk-tksoft) wrote :

Run into the same/similar issue.
A desktop application launcher wouldn't work. The correct icon didn't show and when I clicked on it, I got the same ... trusted warning with only a cancel option.
The .desktop file was executable, so that wasn't the issue.
I tracked down the problem to the Desktop being on a partiton marked "noexec."
I solved the problem by copying the launcher to another partition (with no noexec flag), and then creating a link to that launcher on the Desktop. The application launcher now works and the correct icon shows.

adarsha joisa (adarsha-joisa) wrote :

I've tried everything possible to make it trusted, including changing the file permissions, and all. Nothing is allowing me to "mark the application launcher as trusted"!!!! Somebody please help!!

anantshri (anant-shrivastava) wrote :

another victim shocked to see non availability of a button.

L3ttuce (ifearx) wrote :

What kind of a feature is this? Are we become Windows? Where does 'trusted' settings go? File permissions (which does not make sense - anyone with the same privileges I have can change that), or some sort of central database/repository?

John H Ring IV (johnhringiv) wrote :

i am new to linux and i need help i have follow what you guys have said and nothing happens can anyone help me?

John H Ring IV (johnhringiv) wrote :

i have been loving Ubuntu but this is ridiculous I'm not great at computers but I am above average and I cant even launch a program I hate to say this but if i can figure this out I'm going back to windows

Douglas Baigrie (dbaigrie) wrote :

A simple work around to the missing option is to Right click the .desktop file, select properties, go to the Permissions tab and check the box marked as "Allow executing file as program".

This is a little strange as AFAIK a launcher is not a standard executable file (does not have shebang, not listed in bin formats etc.)

tsg1zzn (tsg1zzn) on 2010-11-19
affects: ubuntu → meta-gnome2 (Ubuntu)
mati (mati-wroc) wrote :

All workarounds doesn't work when using NTFS filesystem (I have a "backup" usb flash drive with NTFS).
I know security is important, but it's like forcing a man to break into his own house though the window.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in meta-gnome2 (Ubuntu):
status: New → Confirmed
Steven Roose (stevenroose) wrote :

I have this problem with a .desktop file on a non-ext partition, so I cannot mark it as executable. If I try so, it still gives the error.

cmcanulty (cmcanulty) wrote :

Same here can't change .desktop permissions even as sudo

dino99 (9d9) on 2013-05-24
tags: added: gnome3 lucid raring
dino99 (9d9) wrote :

meta-gnome2 is only used by Lucid

tags: removed: raring
dino99 (9d9) wrote :

outdated now

Changed in meta-gnome2 (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments