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

[BlissfulTarpon]

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 (electron/electron#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.

[thearchivalone]

@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

[thearchivalone]

@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

standardnotes/forum#690 (comment)

[thearchivalone]

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 electron-userland/electron-builder#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 #738 and taking another good look at snap packages.

[github12101]

I stumbled upon exactly the same Electron/Debian problem with other software.
Nexusoft/NexusInterface#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: electron-userland/electron-builder#4495 (comment) Although it would need to be done as part of the build process.

[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.

[dylanmorroll]

I can confirm the issue on Debian Bullseye (Testing).
The issue is coming from the electron app being packaged with AppImage (electron/electron#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`

To follow up on this, with the latest version (1.4.19), I believe in step 4 you want to change the exec line to Exec=/home/your_username/.joplin/squashfs-root/AppRun

[scruloose]

@dylanmorroll For the record, if you're going to bother unpacking the AppImage and changing perms to make Joplin run, why not apt install chrome-sandbox (or chromium-sandbox should work too) and replace the AppImage's included chrome-sandbox binary with a symlink to your system's installed one (which has setuid root right out of the box). If you're concerned about security vulnerabilities, giving setuid root to un-vetted binaries that come bundled with an AppImage is not exactly best practice.

[weleoka]

Like you say @scruloose, it makes sense if chrome-sandbox is from an apt package manager installed binary.

This will work for lot's of Electron apps that come as appimages, not just Joplin. So, to start: seems like the package from apt install chromium-sandbox puts the chromium-sandbox executable binary as /usr/lib/chromium/chrome-sandbox.

With that in mind lets get going (you'll have to edit these commands depending on your download location and user name):

# install a trusted and signed package with the needed sandbox binary (it's only 800KB  total or so) 
apt install chromium-sandbox

# Create and cd to a dedicated joplin dir
mkdir /home/your_username/myapps/joplin
cd /home/your_username/myapps/joplin

# Make the downloaded Appimage executable
chmod +x /home/your_username/downloads/Joplin-insert-version-here.AppImage

# Extract the downloaded appimage to the joplin dir
/home/your_username/downloads/Joplin-insert-version-here.AppImage --appimage-extract

# cd into the extracted filesystem-root folder
cd squashfs-root

# Backup appimage inluded sandbox binary
mv chrome-sandbox chrome-sandbox.bak

# Symlink to the apt installed sandbox binary
ln -s /usr/lib/chromium/chrome-sandbox chrome-sandbox

# Run joplin from current dir
./AppRun

To upgrade it's the same story as installing, just start by deleting squashfs folder rm -r squashfs, then do the whole thing again: extracting the Appimage and backup, then symlinking the chromium-sandbox binary.

For launcher/desktop shortcut create a file ~/.local/share/applications/joplin.desktop or /usr/share/applications/ (but to make available to all users of your computer you'd have to put the squashfs with different permissions and in a different location).

File: joplin.desktop contents:

[Desktop Entry]
Encoding=UTF-8
Name=Joplin
Comment=Joplin for Desktop
Exec=/home/your_username/myapps/joplin/squashfs-root/AppRun	
Icon=joplin
StartupWMClass=Joplin
Type=Application
Categories=Office;

(edited to include make download executable in order to extract it, and launcher .desktop file)

[guerrajose]

@weleoka

It works perfectly fine for me, thanks!
Just a few corrected typos below chmod +x ; ./AppRun; Exec=/home/your_username/myapps/joplin/squashfs-root/AppRun

# install a trusted and signed package with the needed sandbox binary (it's only 800KB  total or so) 
apt install chromium-sandbox

# Create and cd to a dedicated joplin dir
mkdir /home/your_username/myapps/joplin
cd /home/your_username/myapps/joplin

# Make the downloaded Appimage executable
chmod +x /home/your_username/downloads/Joplin-insert-version-here.AppImage

# Extract the downloaded appimage to the joplin dir
/home/your_username/downloads/Joplin-insert-version-here.AppImage --appimage-extract

# cd into the extracted filesystem-root folder
cd squashfs-root

# Backup appimage inluded sandbox binary
mv chrome-sandbox chrome-sandbox.bak

# Symlink to the apt installed sandbox binary
ln -s /usr/lib/chromium/chrome-sandbox chrome-sandbox

# Run joplin from current dir
./AppRun

To upgrade it's the same story as installing, just start by deleting squashfs folder rm -r squashfs, then do the whole thing again: extracting the Appimage and backup, then symlinking the chromium-sandbox binary.

For launcher/desktop shortcut create a file ~/.local/share/applications/joplin.desktop or /usr/share/applications/ (but to make available to all users of your computer you'd have to put the squashfs with different permissions and in a different location).

File: joplin.desktop contents:

[Desktop Entry]
Encoding=UTF-8
Name=Joplin
Comment=Joplin for Desktop
Exec=/home/your_username/myapps/joplin/squashfs-root/AppRun	
Icon=joplin
StartupWMClass=Joplin
Type=Application
Categories=Office;

(edited to include make download executable in order to extract it, and launcher .desktop file)

[weleoka]

Thank you @guerrajose. I updated my answer which fixes the typos.

Just a few corrected typos below chmod +x ; ./AppRun; Exec=/home/your_username/myapps/joplin/squashfs-root/AppRun

[mYnDstrEAm]

@weleoka Doesn't using /usr/lib/chromium/chrome-sandbox diminish the sandboxing, breaking the isolation between all apps that use /usr/lib/chromium/chrome-sandbox? I don't know how chrome-sandbox works so that's why I'm asking.

[scruloose]

@mYnDstrEAm I'm not an expert in the subject, but I'm reasonably sure the answer is no. The point of that chrome-sandbox utility is that whenever a user invokes it, it starts with root privileges, uses those privileges to set up a (new, unique, temporary) sandboxed environment, then drops root and runs the target program as the regular user who invoked it, inside the sandbox. Keep in mind that if different users run a program from a shared system location (usr/bin/libreoffice, /usr/lib/chromium/chrome-sandbox, whatever), each user gets their own separate instance of the running program, subject to each user's individual privileges. Eg, just because we might both launch libreoffice from a shared executable file in /usr/bin (even at the same time), if I tell libreoffice to save a file in your home directory, it'll still fail with a permission denied error, because my running instance only has my privileges, userid, file access rights, etc.

Trusting the distro-supplied chrome-sandbox utility to do its job is by far the safest and most trustworthy option, compared to enabling "user namespaces" in the kernel (which Debian doesn't enable by default because a steady stream of exploitable bugs keep being found in the implementation) or giving setuid root to some unverified binary you downloaded from somewhere on the internet.

[arrowmaster]

(which Debian doesn't enable by default because a steady stream of exploitable bugs keep being found in the implementation)

Debian has enabled user namespaces in the 5.10 kernel currently available in unstable. It should be available soon in Bullseye so user namespaces will be enabled in the next stable release expected this year.

[PolGZ]

Like you say @scruloose, it makes sense if chrome-sandbox is from an apt package manager installed binary.

This will work for lot's of Electron apps that come as appimages, not just Joplin. So, to start: seems like the package from apt install chromium-sandbox puts the chromium-sandbox executable binary as /usr/lib/chromium/chrome-sandbox.

With that in mind lets get going (you'll have to edit these commands depending on your download location and user name):

# install a trusted and signed package with the needed sandbox binary (it's only 800KB  total or so) 
apt install chromium-sandbox

# Create and cd to a dedicated joplin dir
mkdir /home/your_username/myapps/joplin
cd /home/your_username/myapps/joplin

# Make the downloaded Appimage executable
chmod +x /home/your_username/downloads/Joplin-insert-version-here.AppImage

# Extract the downloaded appimage to the joplin dir
/home/your_username/downloads/Joplin-insert-version-here.AppImage --appimage-extract

# cd into the extracted filesystem-root folder
cd squashfs-root

# Backup appimage inluded sandbox binary
mv chrome-sandbox chrome-sandbox.bak

# Symlink to the apt installed sandbox binary
ln -s /usr/lib/chromium/chrome-sandbox chrome-sandbox

# Run joplin from current dir
./AppRun

Thanks for the info @weleoka! In my case (Debian stable) I get:

[6471:0122/134344.516982:FATAL:zygote_host_impl_linux.cc(117)] No usable sandbox! Update your kernel

But as @arrowmaster said

(which Debian doesn't enable by default because a steady stream of exploitable bugs keep being found in the implementation)

Debian has enabled user namespaces in the 5.10 kernel currently available in unstable. It should be available soon in Bullseye so user namespaces will be enabled in the next stable release expected this year.

This should be (hopefully!) solved in the next stable release, if gets 5.10 Kernel

[Moltkex]

This should be (hopefully!) solved in the next stable release, if gets 5.10 Kernel

Yes, it has. I'm currently on Bullseye with kernel 5.10.5, just checked and Joplin can now be run without the --no-sandbox flag
So glad I thought of checking this thread again, otherwise I wouldn't have known. I'm editing joplin.desktop and delete the --no-sandbox from the exec line right now! 😁

[roman-r-m]

Can this be closed then?

[cvandesande]

I think so, officially the Debian patch that disabled user namespaces (that causes this issue) was removed in Dec 2020 according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446

If you run the Debian 10 (Buster) stable kernel 4.19 you will still be affected by this issue.
If you upgrade to Bullseye (which will become the new stable release in a few months) you will not be affected.
If you install the 5.10 kernel from Buster-backports you will not be affected.

[roman-r-m]

Thanks, I'll close the issue then but feel free to reopen if needed.

[3lpsy]

Instead of creating a new issue, thought I'd just post it here instead as I recently encountered this on Arch.

Initial Error

I wanted to post this in case anyone encountered the same error.

Running the joplin desktop produces the following error:

[49540:0610/103206.751761: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 /usr/share/joplin-desktop/chrome-sandbox is owned by root and has mode 4755.
/usr/bin/joplin-desktop: line 7: 49540 Trace/breakpoint trap   (core dumped) ./@joplinapp-desktop "$@"

This happened after a system upgrade. Running chmod on the sandbox bin did not fix the error.

Work Around

sudo mv /usr/share/joplin-desktop/chrome-sandbox /usr/share/joplin-desktop/chrome-sandbox.bak
sudo ln -s /usr/lib/electron/chrome-sandbox /usr/share/joplin-desktop/chrome-sandbox

The solution is similar to the one mentioned above, but IMO is simpler. There could be advantages to the above solution that I am not aware of though.