Linux: 2.0.0 fails to start

[monga]

[193209:0407/164939.241277:FATAL:setuid_sandbox_host.cc(157)] 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_jitsi-KCGvvK/chrome-sandbox is owned by root and has mode 4755.

I was a happy user of the previous version, but now it fails with the above error.
I'm on an Debian unstable system (x86_64), with kernel 5.5.1

As a workaround, I found out (see electron/electron#17972) that

sudo sysctl kernel.unprivileged_userns_clone=1

makes it work again.

[saghul]

Thanks for the report!

[btlogy]

I've seen the bug while building from master yesterday.
But I was too busy getting v1.1.1 running on many devices to start digging...
Thanks to the auto-update feature, all those devices are now failing on this FATAL error after updating in the background :-/

FATAL:setuid_sandbox_host.cc(157)]` 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_jitsi-tMA386/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

I'm using mostly Debian 10 stable with kernel 4.19.98-1 and the problem persists with v2.0.0-beta2.

Thanks @monga for the workaround. 👍
It helps me too.

And thanks everyone else to be working on improving this app. 👍
Got most of my family using it since the lock down.
And the electron app is much easier and perform better than the web version.

REM: I'm getting something working on Raspbian too, but with many issues to fix (unstable cam, weird noisy sound and abi error while packaging).

[gerroon]

The thing about the work around is that you are going against the Debian's security settings. And one still needs the admin rights to get that fix.

I do hope that there is a fix with this during appimage packaging.

[saghul]

I could reproduce it with Ubuntu 19.10 by setting sudo sysctl kernel.unprivileged_userns_clone=0 myself, since it seems to default to 1.

Hopefully we can solve this quickly, but if anyone has ideas on how to fix it, they'd be more than welcome.

[saghul]

Tried to fix it on #235 and made a beta 4, but alas the problem persists :-/

[awlx]

@saghul we also saw the Problem, that's why we released the deb so People can start the stuff with --no-sandbox, which helps those people. The problem seems only to exist for Debian Buster and running everywhere without sandbox does not seem a good idea.

[gerroon]

I use other Electron apps like Trilium and Rocket.Chat, they release .deb so this is no issue

[jmcclelland]

@saghul we also saw the Problem, that's why we released the deb so People can start the stuff with --no-sandbox, which helps those people. The problem seems only to exist for Debian Buster and running everywhere without sandbox does not seem a good idea.

Where can i find the .deb file for the 2.0.0. release?

[awlx]

@saghul I can make a PR to add it if interested

We build it already and it seems to work fine:
https://github.com/freifunkMUC/jitsi-meet-electron/releases/latest

[hex-m]

Other Electron applications have the same problem. Riot chose to set the SUID bit, Signal added --no-sandbox to their launcher.

[vladimiry]

SUID bit solution is not suitable for AppImage and Snap packages, so normally --no-sandbox gets used there (the --no-sandbox gets injected into the package, so end users don't need to do anything). Other package types can use the SUID bit scenario.

[saghul]

@awlx Nice! Sure thing! What approach did you follow to get it working?

[awlx]

It's to be honest pretty simple as electron-builder has a built target which is called "deb" :).

[vladimiry]

@awlx electron-builder sets the SUID bit for the deb package but this project ships AppImage linux package only and electron-builde doesn't yet embed the --no-sandbox arg into the package of this type. So right now in the case of AppImage case I simply unpack it, apply the needed change and pack it back. I just prefer the repackaging rather than patching the electron-builder module itself as Signal does.

[saghul]

@awlx We don't do debs, this problem seems to manifest differently for AppImages.

@vladimiry Thanks for the insight! I think I'd go with the patching, since it's a tad simpler to maintain, at least for now.

I'll try go get a PR up later today. Thanks for the help!

[saghul]

I think I misread @vladimiry 's comment 🤦 I've spent some time trying to get it to work but AFAICT doing the repackage-package dance might be the only way forward, and I have no energy left for that.

At least with the current way it will work for thoe who want to create Debian packages...

[jcz1]

I vote for debian packages :-)

[tanty]

Would creating a flatpak help here?

[gregorydk]

Would creating a flatpak help here?

Yes, flatpak always helps. Flatpak runs on all distro's, has integration for all desktops and the package can be upgraded with software center if published on Flathub.

[hferreiro]

Would creating a flatpak help here?

@tanty: https://github.com/flathub/org.jitsi.jitsi-meet

[tanty]

@hferreiro thanks!

https://flathub.org/apps/details/org.jitsi.jitsi-meet

[gregorydk]

@hferreiro Thanks!

[saghul]

CLosing as this is now documented in our readme and nothing we can act upon.