Joplin: Appimage cant be run due to permissions

[gerroon]

Hi

The Joplin-1.0.177.AppImage version seems to be having some issue with permissions. Since this is not a proper app it is not possible fix the permission prior to launching and running with sudo also gives Running as root without --no-sandbox is not supported. See https://crbug.com/638180

I am running it on Debian bullseye/sid

[371637:1230/125237.503965: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_Joplinj7cZY9/chrome-sandbox is owned by root and has mode 4755

[matcharles]

Are there any update on this? I am getting the same problem on Kali (being root on default account).

When I use the --no-sandbox option, I will get a Unknown flag:--no-sandbox

I am using v1.0.177 appimage running Kali on 4.19.28 in vmware

v1.0.175 does work properly.

[Poldi1977]

Since version 1.0.178 I also get the error on my Debian system. Version 1.0.175 runs without errors.

[weddi-eddy]

I just ran backwards from the latest version of the app images and I can confirm that version 1.0.176 is the last version that runs without issue on Debian Testing. 177 and 178 both fail to run with the above mentioned issues and behaviour.

[vsimkus]

I can confirm the issue on Debian Bullseye (Testing).
The issue is coming from the electron app being packaged with AppImage (https://github.com/electron/electron/issues/17972), since the chrome-sandbox permissions cannot be preserved in an AppImage.

A temporary workaround is to set sudo sysctl kernel.unprivileged_userns_clone=1, which is _not_ recommended. Read more about this here.

Edit: The workaround posted below is a better option that does not open you up to security vulnerabilities. The steps are as follows:

1. Unpack the AppImage with ./Joplin.AppImage --appimage-extract.
2. Change owner of chrome-sandbox sudo chown root chrome-sandbox
3. Change permission of chrome sandbox sudo chmod 4755 chrome-sandbox
4. If you want the desktop icon to work you will also need to change the exec line in ~/.local/share/applications/appimagekit-joplin.desktop to Exec=/home/your_username/.joplin/squashfs-root/joplin

[gerroon]

Run the AppImage with --appimage-extract then fix the permission

However as of now appimage packaging is broken for Debian based distros since messing with distro permissions should not even be considered to run an app.

[bedwardly-down]

@tessus anyway this could possibly be marked as an upstream bug since it seems to be a Debian specific issue not related to Joplin?

[tessus]

We switched to Electron 7. Apparently that was not a problem with Electron 4 or the builder which creates the image. Unfortunately there is nothing we can do in Joplin.

So how do you run other sandboxed Electron apps on Debian buster? This is not Joplin specific.

[gerroon]

I use Trilium and Riot as well and those do not seem to have any issues of such. Riot had it for a minute but they resolved it back then, not sure how they did it.

[tessus]

They probably set the kernel parameter before starting the app or removed the sandbox. Either way, this is not a Joplin specific issue. Set the kernel paramter properly and all is good.

Please ask debian why the heck they think that running a sandboxed app as a non-root user is a bad thing? Or any distro really, which uses this idiotic default.

Maybe Laurent has an idea how to solve this in Joplin, but IMO this is not a Joplin issue.

[gerroon]

I doubt that a package would be allowed modify kernel parameters at will like that, but it is a curious case for sure.

[tessus]

I doubt that a package would be allowed modify kernel parameters at will like that,

You are right of course. Not sure why I thought it could. Maybe I mixed it up with an ENV var and a different issue. Let's see, if Laurent can come up with something.

Btw, here's also a discussion going on: https://discourse.joplinapp.org/t/the-new-appimage-joplin-1-0-177-appimage-installation-issues/4966?u=tessus

[gerroon]

I think it is something to do with .appimage packaging Becasue those apps I mentioned are provided as .deb packages.

[tessus]

IMO the script or tool or whatever created the AppImage has to be fixed.

[diogogomes]

Please ask debian why the heck they think that running a sandboxed app as a non-root user is a bad thing? Or any distro really, which uses this idiotic default.

Not idiotic default because is more secure and after all is Chromium/Electron upstream related and not Linux specific:

https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md

[bedwardly-down]

@tessus and @diogogomes , according to the official builder documentation, debian packages can be built from the same script as AppImages. Idk if it matters if the build system is debian or not.

[diogogomes]

I don't work with electron but do you think that this can help?

https://www.electronjs.org/docs/api/sandbox-option

https://github.com/standardnotes/forum/issues/690#issuecomment-551103015

[bedwardly-down]

That honestly doesn't look valuable at all to what is happening here. That just explains how to enable and disable the sandbox and the pros and cons for just that

[diogogomes]

Okay. I thought that the issue was how to enable the sandbox and it seems not fixed yet in the electron builder for appimages, only for snap and deb packages.

I hope you can find a solution.

[vsimkus]

So how do you run other sandboxed Electron apps on Debian buster?

In many cases they run it with the --no-sandbox cmd argument, which you could add to the Joplin exec script in AppRun. With Joplin this allows the electron app to start, but then Joplin tries to parse the command-line arguments too and throws Unknown flag:--no-sandbox. So this is fixable on the Joplin side.

I think for the most part, running the electron app without the electron sandbox as an AppImage could be ok if you used AppImage sandboxing such as firejail.

Please ask debian why the heck they think that running a sandboxed app as a non-root user is a bad thing?

The issue is the other way around and not with Debian, but with electron (see https://github.com/electron-userland/electron-builder/issues/4495). Electron requires to run the chrome-sandbox with root permissions. Debian is a security-first distribution and hence does not allow that by default.

It might also be worth reviving the thread in https://github.com/laurent22/joplin/issues/738 and taking another good look at snap packages.

[curious0101]

I stumbled upon exactly the same Electron/Debian problem with other software.
https://github.com/Nexusoft/NexusInterface/issues/56

Can someone have a look? This could be fixed in the Electron as I understand.

[laurent22]

For information, there's a script that can be used to fix this: https://github.com/electron-userland/electron-builder/issues/4495#issuecomment-580864274 Although it would need to be done as part of the build process.

[wibrt]

Confirmation of this behaviour on debian buster (stable)

$ ./Joplin.AppImage 
[17573:0225/160204.555416: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_JoplinlsWX2o/chrome-sandbox is owned by root and has mode 4755.

Firejail with the older version also results in a error:

$ firejail --debug --profile=/home/user/.config/firejail/joplin.profile --appimage Joplin-1.0.175-x86_64.AppImage
Reading profile /home/user/.config/firejail/joplin.profile
Found disable-common.inc profile in /etc/firejail directory
Reading profile /etc/firejail/disable-common.inc
Found disable-passwdmgr.inc profile in /etc/firejail directory
Reading profile /etc/firejail/disable-passwdmgr.inc
Found disable-programs.inc profile in /etc/firejail directory
Reading profile /etc/firejail/disable-programs.inc
Autoselecting /bin/bash as shell
Configuring appimage environment
AppImage ELF size 100024
Mounting appimage type 2
Error mounting appimage: appimage.c:122 appimage_set: Invalid argument

This makes joplin unfortunately unusable on Debian

[initinfosec]

to this end, I've compiled the app as a .deb after building from source, changing the permissions of chrome-sandbox to the expected ownership of root:root and a chmod of 4755.

Once done, I was able to package to deb, install with sudo dpkg -i joplin.deb, and confirmed it works like a charm. [N.B. - anyone who tries this please do not use the install script - i'm still working on it.]

@laurent22 - is there any plan to release a .deb variant? From what I can tell, AppImage doesn't seem keen on providing a work around, and the usernamespace fix for debian seems a bit heavy-handed.

I provided a rationale and PoC here: https://github.com/initinfosec/joplin-debfix

[apologies for the lack of proper fork, etc. I'm new to github and not a developer. I can clean this up as needed if there's a more 'official' route to go.]

[bedwardly-down]

@initinfosec I've already attempted to pass this by him and the Joplin team is not officially supporting any Linux app type outside of AppImage. There's just too many variations and not enough resources available to handle them all. If you decide to use a debian version, don't expect any major bug support due to this fact. The actual team is like 4 or 5 people total and the rest of us are contributors, users, mods for the forums, or mentors for our recent Google Summer of Code acceptance. So, it's literally just not enough man power to support everything possible.

Now, if you want to have a user repository that is approved by the Debian development team, Joplin does have a section for unsupported but distro sanctioned versions available.

[initinfosec]

@initinfosec I've already attempted to pass this by him and the Joplin team is not officially supporting any Linux app type outside of AppImage. There's just too many variations and not enough resources available to handle them all. If you decide to use a debian version, don't expect any major bug support due to this fact.

understood, thanks for the info.

[laurent22]

I mean we can't release a .deb ourselves as I'm afraid it would be difficult to maintain and I don't know much about this format (I've tried once to create one for a different app, and my mind was blown at the complexity of the format, especially compared to how user-friendly Homebrew is for example).

But I guess if we had an expert on board who knows this format well and can maintain it, it could make sense to release it via the project. Actually what is the recommended release format for GUI app on Linux these days? Can a .deb file take care of all the necessary system integration (adding the icon, etc.)? I get the feeling that, despite its flaws, AppImage is as good as it gets, but perhaps we should drop it and release something else instead?

[tessus]

.deb only works for Debian based systems. Thus we can't replace the AppImage with .deb or .rpm.

AppImage is the closest we can get to a universal format. A binary tarball would also be possible, but it doesn't take care of icons and integration with the DE.

[gerroon]

Except that it is not universal as of now given that it is broken on Debian based systems when it comes to Electron apps.

[initinfosec]

I mean we can't release a .deb ourselves as I'm afraid it would be difficult to maintain and I don't know much about this format (I've tried once to create one for a different app, and my mind was blown at the complexity of the format, especially compared to how user-friendly Homebrew is for example).

But I guess if we had an expert on board who knows this format well and can maintain it, it could make sense to release it via the project. Actually what is the recommended release format for GUI app on Linux these days? Can a .deb file take care of all the necessary system integration (adding the icon, etc.)? I get the feeling that, despite its flaws, AppImage is as good as it gets, but perhaps we should drop it and release something else instead?

If I was willing to build Debian ports from each of your major releases, do I need to clear anything with you? I completely understand you're not wanting to fragment the ecosystem. I'm also not a developer myself, and understand that this port would not be officially supported from your perspective. There was mention of a section for unsupported but distro-specific variants -- I need to look into this.

Either way, appreciate your response. Have a great one and thanks for the awesome app.

[initinfosec]

.deb only works for Debian based systems. Thus we can't replace the AppImage with .deb or .rpm.

AppImage is the closest we can get to a universal format. A binary tarball would also be possible, but it doesn't take care of icons and integration with the DE.

That was my thinking as well. AppImage works well as a best effort with most distros. The fact that this particular issue is specific to Debian variants and electron makes me think that the appImage format is still likely the best candidate.

https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison

[gerroon]

There are many apps that ditributes .appimage along with debs I do get why it is implied that it is one or the other here.

[weleoka]

The fact is that AppImages can run on debian just fine. The issue is the sandbox.

I think many users of Joplin would be OK with passing the flag --no-sandbox to run the application, the problem is that that does not work with the current AppImage build of Joplin! As an example the AppImage for Signal Desktop is easily run with --no-sandbox.

Of course running Joplin without the sandbox is not ideal at all, but at least it's something!

[weddi-eddy]

Yeah. Normal user here who has Debian, Windows and Android. The --no-sandbox or .deb options work for me. I would really jist want a way to run it without an older version.

Perhaps the .deb is a temporary solution until appimage or Debian fix something?

Unofficial isn't bad. Think binaries from OpenSSL.

[initinfosec]

I mean we can't release a .deb ourselves as I'm afraid it would be difficult to maintain and I don't know much about this format (I've tried once to create one for a different app, and my mind was blown at the complexity of the format, especially compared to how user-friendly Homebrew is for example).
But I guess if we had an expert on board who knows this format well and can maintain it, it could make sense to release it via the project. Actually what is the recommended release format for GUI app on Linux these days? Can a .deb file take care of all the necessary system integration (adding the icon, etc.)? I get the feeling that, despite its flaws, AppImage is as good as it gets, but perhaps we should drop it and release something else instead?

If I was willing to build Debian ports from each of your major releases, do I need to clear anything with you? I completely understand you're not wanting to fragment the ecosystem. I'm also not a developer myself, and understand that this port would not be officially supported from your perspective. There was mention of a section for unsupported but distro-specific variants -- I need to look into this.

Either way, appreciate your response. Have a great one and thanks for the awesome app.

@initinfosec I've already attempted to pass this by him and the Joplin team is not officially supporting any Linux app type outside of AppImage. There's just too many variations and not enough resources available to handle them all. If you decide to use a debian version, don't expect any major bug support due to this fact. The actual team is like 4 or 5 people total and the rest of us are contributors, users, mods for the forums, or mentors for our recent Google Summer of Code acceptance. So, it's literally just not enough man power to support everything possible.

Now, if you want to have a user repository that is approved by the Debian development team, Joplin does have a section for unsupported but distro sanctioned versions available.

I would absolutely love to be a part of building a .deb variant, first unofficially, but if the need/usage found momentum, perhaps if/as @laurent22 saw fit later on.

What's the SOP for getting involved in the unofficial distro-specific builds - you mentioned Joplin had a 'section' for that - is that a separate branch?

[bedwardly-down]

Not a separate branch but i also don't know how Debian handles unofficial packages and user repositories. The unofficial build linked in the docs on the main website is from the Arch User Repository, and the official Arch Dev Team are pretty strict about who can contribute packages there despite the repository not being officially supported or maintained by them. They pretty much just act as gatekeepers and every so often clean out unmaintained packages and whatnot.

[initinfosec]

Not a separate branch but i also don't know how Debian handles unofficial packages and user repositories. The unofficial build linked in the docs on the main website is from the Arch User Repository, and the official Arch Dev Team are pretty strict about who can contribute packages there despite the repository not being officially supported or maintained by them. They pretty much just act as gatekeepers and every so often clean out unmaintained packages and whatnot.

understood, I just wanted to check if I needed to do anything from the Joplin side to get @laurent22 's "blessing" even though it's not an official build. If there are no wishes from him or the team in that regard, I'll go ahead and start pursuing that path.

[bedwardly-down]

To be fair, i haven't been around here very long and am not always sure what's going on behind the scenes. This is also mainly Laurent's project and I'm primarily here attempting to help in whatever ways i can. I think it's the most any of us can do while this project grows.

[initinfosec]

To be fair, i haven't been around here very long and am not always sure what's going on behind the scenes. This is also mainly Laurent's project and I'm primarily here attempting to help in whatever ways i can. I think it's the most any of us can do while this project grows.

understood thanks - i'll wait to see what he says as I don't want to step on toes. Thanks.

[bedwardly-down]

Also, this is not the final build, just a pre-release build to iron out bugs for the next official one since this one has a pretty hefty amount of additions added

[tessus]

the problem is that that does not work with the current AppImage build of Joplin!

Yes, the pre-release does and thus it will also be in the next release.

[tessus]

@initinfosec no worries. You can go ahead, but please note that we'll send people your way, when they have an issue wiith .deb. ;-)

Here's the repo and maintainer for the rpm packages: https://github.com/taw00/joplin-rpm

[laurent22]

If the .deb is stable enough and updated often enough, we could link it from the web page like the Arch Linux one. @initinfosec, how would it be installed?

[initinfosec]

If the .deb is stable enough and updated often enough, we could link it from the web page like the Arch Linux one. @initinfosec, how would it be installed?

dpkg would be the initial install route until/unless it gets included in a repository for apt.

Appreciate it, looking forward to trying to help out.

[gerroon]

This is how Signal handles it seems

https://github.com/signalapp/Signal-Desktop/commit/1ca0d821078286d5953cf0d598e6b97710f816ef

[scruloose]

Being the kind of person who runs Debian on my personal laptop, I'm not entirely comfortable with setting SUID root on a binary that came bundled in a download from some guy's Github repo (nothing personal, @laurent22!), so...

I got Joplin to run on my Debian Bullseye system using a variation of the workaround detailed by @vsimkus (thanks!):

• install either chrome-sandbox or chromium-sandbox from official repos
• install appimage-tool from their official repo
• unpack the Joplin appimage with --appimage-extract, as described by @vsimkus
• delete or rename the included chrome-sandbox binary, and replace it with a symlink to your system's installed one; eg /usr/lib/chromium/chrome-sandbox
• repack the appimage; eg ARCH=x86_64 ./appimagetool-x86_64.AppImage joplin.AppDir/

Note: when repacking the Appimage, I specified the output file and location to be identical to where I had been running the official one from (~/.joplin/Joplin.AppImage). This way, the desktop launcher works without editing. Repacking the Appimage is entirely optional, but it appeals to my sense of tidiness.

[scruloose]

@laurent22: I wonder whether it would be possible to make a Debian-friendly Appimage by having the Joplin launcher check for system-installed chrome-sandbox (possibly also check for bubblewrap, which seems to be picking up the torch of SUID sandboxing as Chrome moves away from it).

That way, if the user already has a SUID-root sandbox installed, you can use it without the obvious permission problem. (Because yeah, a user-installed package is obviously not able to set its own executables SUID root. That's textbook privilege escalation.) If the launcher finds neither a SUID-root sandbox nor the kernel's unprivileged userns feature, it should throw an error message telling the user that in order to use Joplin they can either enable the kernel unpriv-userns feature or install one of chrome/chromium(/bubblewrap?) SUID-root sandbox.

Does that sound reasonable?

[initinfosec]

@scruloose - this has been talked about and addressed some bit earlier in the thread. At least when I talk to him, there was no plans for necessarily modifying the app image format, although I suppose it could be done on the installer script with some conditional checks. I tried to go that route and verified it worked, but it was pretty inelegant IMO.

I talked with Laurent and got permission to rebuild an unofficial copy as a Debian port. I thought that was a lot cleaner. I don't update it as often as the official package, but you can see my rationale and test it out if you want here: https://github.com/initinfosec/joplin-debian

[gerroon]

Any reason why Joplin is not provided as .deb as well? Most Electron packages do like Rocket.Chat, Trilium etc

[scruloose]

@initinfosec: I agree that it's not the most elegant, and I personally am a firm believer in deb packages. However, if the Joplin docs are going to direct people to the Appimage as the official installation method for Linux, and Joplin's small dev team only has the resources to maintain that one package format, I'd say it's kind of important for the official Appimage not to just silently fail on one of the biggest Linux distros out there. The current situation rather defeats the purpose of using Appimage: the whole point is for it to be an easy portable app package that 'Just Works' for end users regardless of their distro, thus sparing the developers exactly the "it doesn't work on my distro" conversation we're having now.

Because of that, I think that—if it's feasible—it would be highly preferable for the Appimage's launcher script not to blindly assume that kernel unpriv-userns is enabled, but rather do a quick conditional check for both SETUID-root and kernel namespace sandboxing options, use them if present, and if none are available then provide the user with an error dialog indicating why Joplin didn't launch and what they can do about it.

Given that:

• users are going to plop the Appimage down on Debian systems and expect it to Just Work,
• the pretense that Appimages don't have dependencies obviously doesn't hold true for this situation, and
• packaging a SUID-root sandbox binary in the Appimage itself doesn't work;

the least-worst workaround as far as I can see is to have the Appimage's setup script check for the dependencies and tell the user if they're missing. That way they can solve the problem with apt install chromium-sandbox rather than "Hmm, it just didn't launch"/try from terminal window/"What the hell does that mean?"/search Issues/apply arcane DIY fix to the Appimage/try to remember arcane DIY fix every time a new version is released.

Hopefully your unofficial deb won't end up forgotten and get left farther and farther behind as new versions come out, but... I'm probably not the only user who has learned not to count on that, just as a general rule.

[initinfosec]

Any reason why Joplin is not provided as .deb as well? Most Electron packages do like Rocket.Chat, Trilium etc

It just boils down to an intentional choice by the developer to maintain a single format across all Linux distros vs segmenting installers.

[bedwardly-down]

Honestly, the whole should there, should there not be a distro specific release of Joplin keeps going back and forth. It is definitely a developer choice and really should be addressed in concrete and stuck to. The forums are where you'll find most info about it.

[undrwater]

Just wanted to add that the same problem is showing up on Gentoo.
./Joplin.AppImage [509:0611/163601.644458: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_Joplin08OakG/chrome-sandbox is owned by root and has mode 4755. Trace/breakpoint trap

I have sandbox installed, but not appimage. Can't seem to install from source either.

[curious0101]

Yep, Joplin is completely broken.

[weddi-eddy]

Have we tried reaching out to both Electron and Debian to see if there's something we can call agree on?

[tinywrkb]

Can you please release some other Linux target than AppImage like deb or even a tarball.
Compiling from source is a pita, I'm getting here an unusable build due to sqlite3_node even with --update-binary --build-from-source [email protected].

I'm trying my hand at packaging Joplin as a Flatpak and reusing the AppImage release is not a solution for me as AppImage requires access to /proc/self/exe for extraction which doesn't seem to be acceptable as Flatpak is running as root when installing to the local system repo (/var/lib/flatpak), see here.
I can work around this as I'm packaging Joplin for own private use so I don't need to follow Flathub's guidelines but it would be better to have a deb or tarball binary release.

Here's an example of what I've done with Boostnote. Note the zypak module which bypasses chrome-sandbox and negotiates sandboxing of child processes via flatpak-spawn.

[initinfosec]

Can you please release some other Linux target than AppImage like deb or even a tarball.
Compiling from source is a pita, I'm getting here an unusable build due to sqlite3_node even with --update-binary --build-from-source [email protected].

I'm trying my hand at packaging Joplin as a Flatpak and reusing the AppImage release is not a solution for me as AppImage requires access to /proc/self/exe for extraction which doesn't seem to be acceptable as Flatpak is running as root when installing to the local system repo (/var/lib/flatpak), see here.
I can work around this as I'm packaging Joplin for own private use so I don't need to follow Flathub's guidelines but it would be better to have a deb or tarball binary release.

Here's an example of what I've done with Boostnote. Note the zypak module which bypasses chrome-sandbox and negotiates sandboxing of child processes via flatpak-spawn.

Maybe try this.
https://github.com/laurent22/joplin/issues/2246#issuecomment-636144775

I don't think there's any current plan to release an official tar.gz or Deb of the built app

[tinywrkb]

@initinfosec I was more hoping for official binary releases. It's not hard to work around the AppImage like here but it's not the right way and if someone wants to publish via Flahub it won't be accepted like this.

[initinfosec]

@initinfosec I was more hoping for official binary releases. It's not hard to work around the AppImage like here but it's not the right way and if someone wants to publish via Flahub it won't be accepted like this.

As I mentioned earlier to my knowledge there's no official plans by the developer to offer it in a different format then what's currently out there.

[curious0101]

If that's the case, then there is no official plans by the users to use something what is unusable and doesn't work on as fundamental OS as Debian.
This is grave error, without fixing it we can't use it.

[theoden8]

Same as all other (electron-builder only?) generated AppImages, it works on Debian if you tune down security with sysctl kernel.unprivileged_userns_clone=1.

But this is a bad thing to do. So I went to ElectronClient/package.json, and changed:

"author": {
    "name": "myname",
    "email": "myemail"
},
...
"linux": {
    "target": [
        "AppImage",
        "deb"
    ],
}

In case someone wants a quick fix

[tinywrkb]

If the devs are against packaging Debian releases then maybe add a custom target that extracts the Appimage and creates a tarball from the squashfs-root folder. This would be a good source for a Flatpak that could be published via Falthub and would be a more acceptable binary release as it runs in a desktop container.

[curious0101]

If the devs are against packaging Debian releases then maybe add a custom target that extracts the Appimage and creates a tarball from the squashfs-root folder. This would be a good source for a Flatpak that could be published via Falthub and would be a more acceptable binary release as it runs in a desktop container.

And what's wrong with DEB packages, again? Why Flatpak?

[tinywrkb]

I didn't say that there's something wrong with deb packages but repackaging an Appimage build as a tarball would probably be easier than building deb releases with regards to build failures and testing the releases.

[curious0101]

I guess we can come back to this discussion when we have some choice, right now we have whole zero package formats from which joplin can be installed on Debian.

[byarbrough]

I just ran in to this issue with Joplin 1.0.220 on Kali 2020.2. The --no-sandbox option seems to work.

Definitely would love to see a snap, as mentioned in #738

[initinfosec]

I just ran in to this issue with Joplin 1.0.220 on Kali 2020.2. The --no-sandbox option seems to work.

Definitely would love to see a snap, as mentioned in #738

Joplin is now in the Kali 2020.02 repos BTW - a sudo apt install joplin will do the trick

[SSBaez]

Since version 1.0.178 I also get the error on my Debian system. Version 1.0.175 runs without errors.

The same applies for Parrot OS

[easthvan]

UPDATE:

I did succeed with the installation using the AppImage installer app, despite receiving countless various errors it did install the app. I ended up with two shortcuts though.

Folks,

I am new on Linux, installed Ubuntu a few days ago on two PC (tried installing Linux twice in my life years ago), I switched now from Win10, uninstalled Win and loved the Standard Note app on Ubuntu (from store) but now on Debian testing it is impoossible to install and use thsi amazing Standard Note app because of this nightmare AppImage whatever solutution. All I get are various scary error messages, failures, popup error windows whatever commands I type in from "Linux guru" websites. --no -sandbox" or what it says and many other errors. Cannot run it, cannot have a shortcut for it etc Everythig was perfect on this Debian 10 but now after one day on it this AppImages whatever ruined my experience and demolished my trust in Debian, Linux again.

here is the file. Anyone could tell me how to install and run this on the latest Debian 10 test ?

[omicron-b]

@easthvan
Discussion of issues in other apps is off topic here.
Open my profile and drop me an email and I will try to help, or hit a public support forum, like /r/linuxquestions on Reddit

[easthvan]

@easthvan
Discussion of issues in other apps is off topic here.
Open my profile and drop me an email and I will try to help, or hit a public support forum, like /r/linuxquestions on Reddit

Hi,

Thanks for the response.

I guess I was focusing too much on tat specific app (Standard Notes), but I assumed that my case is exactly the same as its in the title of this thread, AppImage cannot be run due to permissions as I have received similar errors as some other people described here.

But thanks for suggesting a Linux support forum! as a noob every help is help for me.