Unable to start 1.0.179 (on Linux)

Support
1

After successfully upgrading to Joplin 1.0.179 on my Debian Testing system (the install/update bug in the script was solved) I’m unable to start/using Joplin:

mw@NUC:~$ .joplin/Joplin.AppImage 
[3060:0125/101629.811532: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_JoplinH6lF4s/chrome-sandbox is 
owned by root and has mode 4755.

There is no file /tmp/.mount_JoplinH6lF4s/chrome-sandbox
Falling back to 1.0.175 works w/o problem!

1 Like
2

Probably this is related:
SUID sandbox helper binary was found, but is not configured correctly #17972

3

I can’t make sense of all these posts. Do you know if there’s a solution for AppImage that we can implement in all this? Ideally some config option we can set, because advanced packaging like wrapping the executable as some users suggest I can’t do.

4

No, I don't know a solution for this.
I tried the suggested option

--no-sandbox

but only got an error message Unknown flag (Joplin 1.0.175 and 1.0.179)

1 Like
5

I can confirm that Joplin 1.0.179 does install on MX Linux MX-18 but is unable to start.

I also get a very similar error message as @miwie, and trying --no-sandbox throws “Unknown flag: --no-sandbox”.

6

I tried running this command, as suggested in the link @miwie referenced above:

sudo sysctl kernel.unprivileged_userns_clone=1

After running this command Joplin 1.0.179 does start and runs as expected!

However the command does not stick through reboots and I do not understand if there are security concerns by running the command.

As of now it does work as a workaround, though.

2 Likes
7

I recommend that you are not changing your kernel’s security parameters to run an application. There is a reason why kernel devs implement such reasons and it just sounds lazy that electron developers are recommending to turn off a security feature.

The thing is that, as of now Joplin can be run only if the user has root access (so she can chmod /chown to root), unpack to apply permissions and pack the appimage back.

@laurent why not provide a simple tarball so that the user can run Joplin with --no-sandbox until there is a fix for the appimage?

2 Likes
8

@kartoo Thanks for your posting. That is exactly my opinion.
But one can find a lot of postings/opinions on this issue. AFAICT the sysctl setting unprivileged_userns_clone was introduced to be able to switch off a patch Debian (and probabely other distros) apply to their kernels. The mainline Linux kernel does not contain this patch, see e.g. What does enabling kernel.unprivileged_userns_clone do?

If this will not be fixed in the Joplin AppImage I need to look for another solution for cross-platform notes :frowning:

1 Like
9

To be honest I trust Debian maintainers more than the Electron devs. The electron devs constantly break and change stuff causing confusion for downstream apps. For instance one was able to click on the tray icon to bring Joplin (or any other Electron app) to front, now that is gone. You need to click to enable a drop down and then you click on show/hide (at least on the systesm that I use), this is a total nightmare for elderly users with sight and physical issues from the usability point of view.

I actually unpacked the Joplin appimage, however it is not accepting ./joplin --no-sandbox That is something to be looked at. I am using the unpacked version with modified permissions (thankfully I have sudo), since I cant find a way to run the app image or run joplin with --no-sandbox

Another option is to publish Joplin as Flatpak or Snap, personally I hate Snap because it creates so many new mounts on my system.

2 Likes
10

Yes, same here on Debian sid, after upgrading, Joplin won’t start anymore.

11

I doubt it. It only allows the kernel to create namespaces (sandboxes) for unpriviledged users. What should be the security impact of that?

While I agree with @kartoo, I also think that this is a valid workaround. You can make it stick by adding it to /etc/sysctl.conf or create a new file in /etc/sysctl.d.

12

Thanks @tessus. I’ll take my chances and use the workaround until it eventually gets fixed. Thanks for helping.

13

The last version I tested on Debian Testing was 176 and that does work. Any version past that does not install.

14

In 1.0.177 we switched to Electron 7. See also this comment

15

So is using this command the only solution? It works, but will I have to enter this command every time I reboot? ```
sudo sysctl kernel.unprivileged_userns_clone=1

Will this problem be solved?
1 Like
16

As Joplin is still not running on Linux - is there a way to install an older version?

This would be highly appreciated :wink: and very helpful for me...

Thank you!

1 Like
17

As I have been looking for a way to ditch Evernote, I was excited to learn of Joplin recently. I first used it a bit on my Mac at work to see what all the fuss was about. Then I decided to give it a go on my Debian Buster OS at home, and came across the same problem.

Is there anyone working on a fix for this? Call me paranoid, but I am not planning on running the workaround mentioned above. I guess I’ll go check Github as well.

1 Like
18

I answered that a few comments above your question: You can make it stick by adding it to /etc/sysctl.conf or create a new file in /etc/sysctl.d .

19

There's no fix for this in Joplin, because it's a problem with 2 upstream projects (electron-builder and chrome-framework) in combination with a default kernel setting in Debian. We can't fix this, unless we make Facebook and Google and/or Debian change their code.

However, there are several workarounds. One is changing the kernel parameter, which is obviously a no-go for you.
Then there was a PR merged that allows you to start the app with the flag --no-sandbox. This will be available in the next release.

2 Likes