Bug 499589 - Attempting to run an AppImage that needs a --no-sandbox from UI just exits without helpful message
Summary: Attempting to run an AppImage that needs a --no-sandbox from UI just exits wi...
Status: CLOSED DOWNSTREAM
Alias: None
Product: kde
Classification: I don't know
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-06 11:38 UTC by Reuben
Modified: 2025-02-06 19:47 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Reuben 2025-02-06 11:38:06 UTC
SUMMARY

This is from Dolphin, but presumably the issue is deeper in KDE.

I can run a downloaded AppImage from Dolphin - when I double click, it pops up a dialog asking if I want to execute it. However, if the AppImage is electron and needs to mount the chromium sandbox(??), nothing will visible happen after clicking "execute". This is suprising and annoying.

KDE should detect this situation, and give a choice (presented in a more explanatory way):
a) Sudo to fix the perms on the sandbox
b) Run without sandbox

STEPS TO REPRODUCE
1. Download Quiqr AppImage (https://quiqr.org/)
2. Attempt to run it from Dolphin

OBSERVED RESULT
Nothing apparently happens, as described. Per Claude, the two alternatives are:

1) Run the AppImage with the --no-sandbox flag:

./your-appimage.AppImage --no-sandbox

2) Set the correct permissions as root:

sudo chown root:root /tmp/.mount_quiqr_huIfd2/chrome-sandbox
sudo chmod 4755 /tmp/.mount_quiqr_huIfd2/chrome-sandbox
./your-appimage.AppImage

EXPECTED RESULT
Containers (hopefully including AppImages) are part of the future. KDE should help remove the friction of using them.

SOFTWARE/OS VERSIONS
Operating System: Kubuntu 24.10
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0
Qt Version: 6.6.2
Kernel Version: 6.11.0-13-generic (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5700G with Radeon Graphics
Memory: 30.6 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: ASUS
Comment 1 David Redondo 2025-02-06 15:08:21 UTC
How should we detect that certain executable needs a random (from the system pov) flag set? The appimage author should make sure that their appimage can run correctly or the appimage itself
Comment 2 Reuben 2025-02-06 17:25:35 UTC
With respect, I don't think this addresses the issue. The issue is: running an AppImage can fail silently. That's unquivocally a bug.

With regard to the flag being "random" - not sure I agree either, though this is more a question of how comprehensively KDE wants to support AppImages. 

a) AppImages can run in a sandbox or without a sandbox - that's a fundamental architecture - not a random flag.

b) Electron is not exactly uncommon. And AppImages that were written in Electron all have this issue. It's detectable by KDE simply by looking at the stdout when you attempt to run it after the user clicks "Execute". It would be feasible for KDE to (as I suggested) pop up a second prompt explaining what happened to the user and offering one of two options.

If it's not a goal for KDE to be able to run AppImages, then I'd suggest removing the current dialog, since it's half assed. Minimal fix here would be to at least show the output when it fails to run. I think a better fix is as I described.
Comment 3 Joshua Goins 2025-02-06 18:09:01 UTC
(In reply to Reuben from comment #2) 
> With regard to the flag being "random" - not sure I agree either, though
> this is more a question of how comprehensively KDE wants to support
> AppImages. 
> 
> a) AppImages can run in a sandbox or without a sandbox - that's a
> fundamental architecture - not a random flag.

Just a correction but your LLM is wrong, --no-sandbox is from the application - AppImages do not have anything to do with that.
Comment 4 Reuben 2025-02-06 18:14:26 UTC
Oh. My bad! It appears to be an electron thing rather than AppImage thing then. 

https://www.reddit.com/r/debian/comments/hkyeft/unable_to_run_appimage_applications_without/ etc
Comment 5 Nate Graham 2025-02-06 18:46:03 UTC
Indeed. Which means the app itself is either mis-written or mis-packaged. If it needs that flag to run successfully, it's the app's responsibility to do so.

Really this is no different from any other misbehaving app. If an app successfully launches but then doesn't show a window or quits immediately, it's the app's fault, and there isn't really anything we can do about it. Showing STDOUT or STDERR won't work because 1) there's no guarantee anything will be printed there and 2) there's no guarantee anything printed there would be related to the issue. Lots of app (including many of our own, unfortunately) print a lot of junk there that doesn't actually indicate a problem.

So please report this to the app's developer or AppImage packager. Thanks!
Comment 6 Reuben 2025-02-06 18:53:07 UTC
> If it needs that flag to run successfully, it's the app's responsibility to do so.

Again, it's every electron AppImage. Not just this single one. This is not a random or niche thing.

They even exit with a specific non zero error code.

But yet another half finished KDE thing I guess. Fine.
Comment 7 Nate Graham 2025-02-06 19:16:39 UTC
Then it's every Electron app's responsibility, or Electron's responsibility.

Basically, if the app is written or packaged so badly that it quits immediately after launching, that's the thing that needs to be fixed. Anything we could do on our side would be an unreliable and potentially misleading band-aid.
Comment 8 Nate Graham 2025-02-06 19:47:58 UTC
So whoever is packaging these electron apps using AppImage needs to do some basic testing to make sure the app at least runs when launched using the GUI. That's literally the bare minimum.