Hi!
I'm trying to use some AppImages on my shiny new Elive 64bit.
I've downloaded the file, run chmod +x and then ran but the problem is the following (example with Balena Etcher):
[23569:0820/100824.959013:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_balenaj26YNf/chrome-sandbox is owned by root and has mode 4755.
/tmp/.mount_balenaj26YNf/balena-etcher-electron: riga 10: 23569 Rilevato trace/breakpoint "${script_dir}"/balena-etcher-electron.bin "$@"
What can I do?
Other appimages works fine (e.g. pCloud)
I see... But why some apps require sudo and other not?
Ok for Balena Etcher, but why for an email client (tutanota)? There's a logical answer or it is just a decision made from the developers?
It's primarily a developer decision but admittedly they have the "worry" that not all distros are alike.
Some allow user mounting/hot-plugging where others still adhere to the old adagium that only root is allowed to.
Some have "sudo", some don't and require "su"
and there's the numerical UID compared to using the user-names.
Not forgetting the permissions needed to run (and inherit) from /tmp differs per distro.
In general, appimages have a problem due to inheriting the uid of the directory they're started from and try to circumvent that by running from /tmp (or they make sure that all permissions are at a user level).
As to "tutanota" ..... I don't see the need of using a dedicated e-mail client to access a host service.
You need to make sure that /tmp/.mount_balenaj26YNf/chrome-sandbox is owned by root and has mode 4755.
That's easy.
sudo chown root:root /tmp/.mount_balenaj26YNf/chrome-sandbox #To change the owner of that dir to root
sudo chmod 4755 /tmp/.mount_balenaj26YNf/chrome-sandbox #To make the dir have mode 4755
It looks easy but isn't .... as that mount will (should)l disappear after the program shuts down i.e you will have to incorporate that into the script.
As it will be mounted by root, the user will not be able to unmount so won't be able to stop the process.
At this point I think I'll run with sudo if needed
At the moment the only appimage that I need (maybe) and that needs sudo privileges is Balena Etcher, but is not used on a daily bases so is not such a problem
Thanks for your reply, I've learned something new today
I'm a command line freako so I never even contemplate a GUI proposition, considering it to be inferior at best and at worst an insult to my intelligence.
Then again my favorite "dd" also requires "sudo" on Elive to access a flashdrive, i.e: "sudo dd if=Downloads/clonezilla-live-2.6.0-37-amd64.iso of=/dev/sdb bs=4M status=progress"
Think about it this way:
Every programmer writes his/her program (functionality) with commandline/script first and adds a GUI as an after-thought to accommodate those who tend to get lost in the options.
It's never the other way round.
I just stumbled upon this old thread because I was looking for a solution for exactly the same problem: some AppImages out of a bunch of them was just working, and some not with the identical error message. Trying to chmod and to chown as suggested above did not work, because after the error the whole process is aborted, and there are no temporary files left. Sudo does not help either. For me the solution was to enter this in the Terminal:
./MyAppImage --no-sandbox
Maybe this helps someone else with the same problem.
Actually a support of AppImage files has been implemented in the last versions (bullseye experimental builds).
(as simple as double-click in the AppImage file in your file-managers)
They only support "do you want to run it as root?" but looking at @Emil last comment seems like more options are needed like --no-sandbox so i committed this improvement, is there any other needed options for it?
Wouldn't it be a better option to have it create a .desktop file and add it to the menu?
That is of course taking for granted the user wants to keep the app.
Personally, I do that with the 'TOR onion browser' by running it and adding/keeping the icon on the dock.
It seems there are no other options needed. AppImages do not always seem to work properly, I have found. I like the idea of a self-sufficient app bringing everything necessary with it and running everywhere. But trying out quite a few of them (out of curiosity) under Linux Mint, I realized that this is not always the case for unknown reasons. I am not a programmer, and I did not always launch them from the terminal, but by double-click. The majority works, but a few refuse to do their job in Linux Mint. Unfortunately there were also some I really was interested in, but what can you do?
Yesterday I copied my AppImage collection over to my Elive Mac, because I was curious how they would behave under Elive. Most of them work there, too, but a couple of them didn't, and it was mostly that sandbox problem, and in one case the update mechanism of the app seemed to get stuck after having found out that there was no new update available.
Some of the AppImages also ask you if you would like to have a menu entry, but not all of them. And there is one other issue: some apps only have a menubar icon when running under Gnome or Cinnamon for instance. In Elive they do run in the background, but you cannot see them or change configurations easily. They also do not show up in the dock. The dock seems do depend on a program having a window.
One probably would have to ask the AppImage developers about finding workarounds for menubar-less distros.
after run it, ask the user if wants to create a launcher for this application ?
ask which application category (image/video/audio, etc) to set it
ask name for app
an icon should be needed too
in such case, the .desktop file can be created, and then the AppImage should be stored somewhere, probably in ~/.local/bin/ is the best place for it
Probably missing libs? it is meant that they should be all the needed ones included (that's the purpose of this format)
To launch them from terminal, just open a terminal on that place and if has exec permissions just run the file itself as "./someapp.appimage"
Can you tell me a few ones that doesn't work? i wanna try them there
Sandbox problem implemented in last updates when double click the file
Yes, you need to ask support for menubar-less desktops (not distros), only gnome (mostly) has that menubar so these applications should support more desktops and not only gnome, that's called desktop-agnostic
In my last post I mentioned a couple of major and minor issues, the most serious one, the sandbox issue has been addressed and fixed (did not come back to my Elive Mac in the meantime; writing from my Mint box now) by you already.
The other two:
Stuck update mechanism
Desktop menu integration question
To begin with the latter: under Mint most (but even there not all, as far as I remember, ask about a desktop menu entry. in Elive they almost never do. And if you click 'Yes', it is no guarantee that there will be one afterwards. Maybe this has something to do with the inner workings of Enlightenment?
The former problem does not occur in Linux Mint (the lockup after the update).
I will run through my Appimages on the Elive machine as soon as possible and report again, so you can see for yourself.
I wonder if we should use that or instead, elive should add its own .desktop system compatible with all the AppImages
Can you tell me about an AppImage application that asks for the .desktop so I can betatest it here and see how it behaves?
yes, the .desktop is probably included but the menu of e16 is not regenerated until your next re-login into the desktop, the menu of your dock instead is always updated so you can verify it from here too
Ok, just give me the links of the AppImage's that has errors in Elive and ill check them there
I did not know that - so I will have to double-check this on my actual Elive installation plus on the new elive+ live system under e16 and e25. I did a brief test run of Elive+ with both e16 and 25, but without focus on anything particular. On startup there are a few discouraging messages about my old computer, but I ignored them, and the 8GB of RAM seem to have been sufficient enough to run everything without restrictions. Nothing was slow, for instance. I used the 5.10 kernel, because I have older hardware, and no bleeding-edge peripherals either. So far the good news.
I will get back to you about the AppImages again.
More good news: I tested all my AppImages under 3.8.27+ with the 10.15 kernel and e16. They all work ok without errors. The only difference between them is that some ask if they should create a menu entry and most don't. I cannot see any reason for this behaviour, but the most important thing is that you can launch them by double-click or in the Terminal, and that they do their job. And even my one and only desktop-agnostic Appimage - BreakTimer - leaves an icon in the Iconbox in the upper left corner, so it is accessible in spite of the fact that e16 has no menubar/taskbar.
In short: I do not see any urgent problems any more...
