# Number of appimages stopped working

**URL:** <https://discourse.appimage.org/t/number-of-appimages-stopped-working/2590>\
**Category:** Using AppImages\
**Created:** [January 23, 2022, 10:33am UTC](https://discourse.appimage.org/t/number-of-appimages-stopped-working/2590 "2022-01-23T10:33:12Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![balrm](https://avatars.discourse-cdn.com/v4/letter/b/d2c977/32.png) [@balrm](https://discourse.appimage.org/u/balrm)\
**Post date:** [January 23, 2022, 10:33am UTC](https://discourse.appimage.org/t/number-of-appimages-stopped-working/2590/1 "2022-01-23T10:33:12Z")

</div>

debian 10 main  
A number of appimages programs used to start. Now they do not. Maybe  
it is due to an update of debian. I cannot tell.  
Starting several appimages from command line returns:  
‘some numbers’ 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\_DeltaCm3TGjB/chrome-sandbox is owned by root and has mode 4755.  
Trace/breakpoint trap  
For instance jitsi-meet-x86\_64.AppImage and DeltaChat-1.22.2.AppImage return the above  
message. krita-5.0.0-x86\_64.appimage starts. What is this about? If updating the  
debian packages resulted in the before mentioned error message, why would that  
be so? Isn’t an appimage autonomous such that in most cases a program will  
start anyway? Thank you.

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [March 31, 2022, 8:46pm UTC](https://discourse.appimage.org/t/number-of-appimages-stopped-working/2590/2 "2022-03-31T20:46:52Z")

</div>

AppImages based on [Electron](https://www.electron.build/) require the kernel to be configured in a certain way to allow for its sandboxing to work as intended (specifically, the kernel needs to be allowed to provide “unprivileged namespaces”). Many distributions come with this configured out of the box (like [Ubuntu](https://ubuntu.com/) for instance), but some do not (for example [Debian](https://debian.org/)).

To temporarily enable unprivileged namespaces, you can run this command:

`sudo sysctl -w kernel.unprivileged_userns_clone=1`

This command will take effect immediately but will not survive a reboot. To permanently enable unprivileged namespaces, run:

`echo kernel.unprivileged_userns_clone = 1 | sudo tee /etc/sysctl.d/00-local-userns.conf`

This command will take effect only on the next reboot.

Please see [https://docs.appimage.org/user-guide/troubleshooting.html#i-have-issues-with-electron-based-appimages-and-their-sandboxing](https://docs.appimage.org/user-guide/troubleshooting.html#i-have-issues-with-electron-based-appimages-and-their-sandboxing) for more information.

If you think that Debian should enable unprivileged namespaces by default (like most other desktop distributions do), then please file an issue with Debian.

---

<div class="post-metadata">

**Author:** ![balrm](https://avatars.discourse-cdn.com/v4/letter/b/d2c977/32.png) [@balrm](https://discourse.appimage.org/u/balrm)\
**Post date:** [April 9, 2022, 1:23pm UTC](https://discourse.appimage.org/t/number-of-appimages-stopped-working/2590/3 "2022-04-09T13:23:10Z")

</div>

> some do not (for example Debian).

Has debian made that decision for security  
or privacy reasons?

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [April 19, 2022, 7:39pm UTC](https://discourse.appimage.org/t/number-of-appimages-stopped-working/2590/4 "2022-04-19T19:39:38Z")

</div>

Don’t know - that would be a question you’d need to ask Debian developers. I would not be surprised if they would cite “security”. But then, Ubuntu isn’t known for being insecure just because they configured this stuff to “just work” out of the box…

---

<div class="post-metadata">

**Author:** ![eBPF](https://avatars.discourse-cdn.com/v4/letter/e/9f8e36/32.png) [@eBPF](https://discourse.appimage.org/u/eBPF)\
**Post date:** [September 29, 2022, 1:44am UTC](https://discourse.appimage.org/t/number-of-appimages-stopped-working/2590/5 "2022-09-29T01:44:28Z")

</div>

Enabling unprivileged user namespaces makes exploiting the linux kernel “easier.” Canonical/Red Hat/et al can “squash” a bunch of exploit chains by changing that default option in their distros.

There’s a huge amount of resources dedicated to this topic compiled at [linux - What does enabling kernel.unprivileged\_userns\_clone do? - Information Security Stack Exchange](https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do) from various reputable sources (LWN/Brad Spengler/Project Zero/seclists.org/Rapid7/…)

---

<div class="post-metadata">

**Author:** ![probono](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/probono/32/81_2.png) [@probono](https://discourse.appimage.org/u/probono)\
**Post date:** [October 1, 2022, 10:11am UTC](https://discourse.appimage.org/t/number-of-appimages-stopped-working/2590/6 "2022-10-01T10:11:24Z")

</div>

Disabling unprivileged user namespaces makes Chromium/Electron based applications require a suid helper binary. Those are also not exactly good for security, especially if you distrust Google.