A discussion on the "chmod +x"


All that really needs to happen is someone writes a patch for nautilus (GNOME Files) to give a more helpful message when someone double-clicks on an AppImage (or on any ELF binary) that doesn’t have execute permission. The message could be something like:

Execute this file as a program?

For security reasons, this program currently does not have permission to run on your computer. If you know where it came from and trust the source, click here to grant permission.

A message like this should pop up even if the user is running appimaged, in my opinion. This is equivalent to the warning given on a Mac when the user tries to run an untrusted .app file.



Would you be able to write this? I wouldn’t even know where to start.


I approached the Nautilus developers. They were friendly and welcoming, but they said that all platforms (Windows, Mac, Linux) are moving away from allowing untrusted executables to run outside of a sandboxed environment. It is highly likely that quite soon, Nautilus will no longer have the the ability to launch programs by double-clicking on them, even if they DO have execute permission. This means the question of prompting for execute permission is moot, because the program won’t run anyway.

They suggested this course of action:

  1. Add the AppImage MIME-type to the open-with list for a sandbox program.
    • Double-clicking an AppImage runs it inside a sandbox.
  2. Add the AppImage MIME-type to the open-with list for GNOME Software.
    • Double-clicking an AppImage opens GNOME Software and asks if the user wants to install the AppImage.

It may also be possible to modify the spec slightly to make AppImages valid flatpak and/or snap packages, but fully self-contained so that they can still be run independently of those packaging tools.

The bottom line from the lead developer for Nautilus was:

csoriano: [with] respect to the file manager: sandbox with perms framework? ok to run, otherwise, no


Sorry to barge in, but how about making small application that can be registered as handler for AppImage mime type? One that would just display window with big “Run It” button and some sandboxing options.

I’m asking because I’ve drafted something like that and come to check if there is any interest for it, finding this thread as first thing :slight_smile:



Appimages Desktop Integration and how to achieve it

Registering a handler for the AppImage mime type would technically be an option, but since it would have to be installed on the system, why not let the optional appimaged daemon handle everything automatically. We could integrate a GUI similar to what you are showing there; but even better we would make it “just work” like on the Mac without asking the user questions.

In any case, please avoid the word “install” in conjunction with AppImages, since they don’t need to be installed.


Sorry, I was under impression that is not (currently?) possible. If that’s not the case, I have nothing to offer :slight_smile:


Benefit of using mime type handler would be, that appimaged would no longer need to watch directories. It doesn‘t matter which directory the appimage is saved to.

I think a mime type association with a handler is the better approach, since it relies on basic mechanisms offered by any DE. After all, double clicking a txt or png file is one of the most basic tasks, thus mime handlers can be considered pretty mature.


Register a mime could help if appimaged (or another software) is present but it has nothing to do with running the appimage itself.
If there’s a daemon present then register the mime is “free as beer”. If there’s no daemon then it’s a no go way.

I think chmod+x or righ-click->permissions->execute it’s not that hard.
When a user works with linux he needs to know a bit about linux. if I want to drive a truck then doesn’t matter if I’m an ace driving karts… the only thing that really matters is if I know a little about truck driving.
Other thing is that we, as developers, want to give the things the easier possible for the users but hey, if the user don’t know how to make a file executable and don’t want to “learn”… then perhaps he will do better sticking with his os and not blaming linux for be “not as windows/macos”.


Well appimaged (or whatever handler is registered) could then do its magic to chmod-then-launch the file in question. It could even display dialogs such as designed above.

If appimaged is capable of handling the mime type, it would enable distros to behave in a way that the appimage devs want to.

I.e. we don‘t rely on distros to implement appimage specific launcher routines, we „just“ need appimaged to be included in the distribution.


Perhaps I didn’t express myself well, I was talking about the cases when the daemon isn’t available (appimaged package not on distro or not available for some reason…).


I completely agree, and I think this is a necessary improvement over having to use low-level file permissions to mark the .appimage as executable. This is the closest thing currently possible to zipped app bundles on the mac, which I’m amazed that none of the linux environments have copied yet.

The executable bit is a low-level function, meant to separate executables from data files in shell scripts and terminal prompts. It’s not user-friendly enough to pass through to users in a GUI environment.

If the user downloads something with an executable file extension and makes a specific intention to run it by double-clicking, then they are expressing their intent. Ideally the GUI would present a warning and/or authentication prompt the first time an executable is double-clicked before running it. Forcing them to chmod or get deep into a unix-level permissions dialog is a bit cruel.

As it stands, it sounds like a tar.gz file with a shell script launcher is more user friendly than an AppImage, because all the user needs to do is extract the file, then double-click to launch. I think the extraction could even be a bonus, because it gives the user a chance to unpack the app in a location of their choice. The only thing to worry about is the user’s unarchiver stripping the executable bits, but presumably that can be covered by a README file which is referenced only if necessary.


I agree - though you can have an AppImage inside .tar.gz just as well, which is what we do. We don’t make use of the AppImage daemon so there’s no downsides to that approach.


Your users might be using appimaged…


Almost none aren’t, so it’s a very beneficial approach atm. I’m not getting any negative feedback at all on this from them.


AppImages are twice the fun with appimaged :wink: