Error open 1.9 Debian Buster

mailspring
[6883:0414/133339.282540: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 /usr/share/mailspring/chrome-sandbox is owned by root and has mode 4755.
`trap’ para punto de parada/seguimiento

Not open 1.9.0 version in Debian Buster

+1 on this.

running with “mailspring --no-sandbox” fixes the issue.

I had to update permissions on the sandbox file to get it running normally using “chmod 4755 /usr/share/mailspring/chrome-sandbox” (you need sudo)

1 Like

How did you install Mailsprung? Via the snap package?

mailspring --no-sandbox
Running database migrations
App load time: 163ms

Running Setup
{“error”:null}
(electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently “false”. It will change to be “true” in Electron 9. For more information please check [Discussion] Requiring Native Modules in the Renderer Process to be NAPI or Context Aware · Issue #18397 · electron/electron · GitHub
Manual update check (updates.getmailspring.com/check/linux/x64/1.9.0-87660767/anonymous/stable) returned 204

now opens

install with package .deb

OK… with permission opens OK
Thanks !

@A350 and @bennetgallein Don’t forget to vote for this issue to raise its priority.

I am also unsure if the deb-building process is open source? I wasn’t able to find it on github on my own. If someone can link me that I can have a look into the issue and submit a PR.

Yes, it is. When you have the for repository cloned, the following command builds the .deb and the .rpm file: nmp run-script build

(Just answering on mobile right now. I hope I remembered the command correctly. Let me know if not)

Hey folks! Hmm, this was an issue with the snapcraft build that we fixed during testing, but afaik it should work fine when Mailspring is installed via the debian package - will take a look at this today. I think that the chrome-sandbox file @bennetgallein mentioned should do the trick, but hopefully we can reelase a patch today or tomorrow with a better fix. I don’t think we want to disable sandboxing except in the snapcraft build (which runs inside the snapd sandbox).

Hey folks—I’ve been looking in to this today and I can’t quite figure out how this is happening.

The debian package (.deb) includes chrome-sandbox file with what looks like the correct permissions:

bengotow@bengotow-virtual-machine:~$ dpkg -c '/home/bengotow/Downloads/mailspring-1.9.0-amd64.deb' | grep chrome-sandbox
-rwxr-xr-x root/root   6259104 2021-04-13 12:32 ./usr/share/mailspring/chrome-sandbox

When I install the deb package with sudo dpkg -i <package.deb> it seems to work fine, is there another method of installing the package that is failing maybe? I think that the permissions on this file are important in this release, but weren’t in the past, because we updated Chromium and the new version does some system level sandboxing.

That might be true. I just installed the 1.9.1 update after I applied the fix i mentioned before and ran again in the same issue.

So there seems to be something that messes up the permissions. I also installed with dpkg as usual.

I also noticed that the permission on the file itself (in the .deb archive) are not 4755 but 0755, but I am unsure how that disables chrome-sandbox from running correctly.

I will clone the repository and try if I can find something.

Also you mentioned that it works on your end? I removed the /usr/share/mailspring folder and installed a freshly compiled version from master but without any success really…

But it just seems to be the setuid bit itself… Also saw the fix you implemented yesterday, but as mentioned above it does not seem to effect the binary in the package.

Same issue here with Version 1.9.1. I’ve manually changed the permissions to 4755 and now it works fine.

1 Like

Since there was just the release of 1.9.2 I want to come back to this issue as this is still the behaviour for me on Debian.