← all posts

· Infra · 3 min read

Installing Mattermost Desktop on Ubuntu 26.04: the .deb is hidden and the tarball doesn't start

I installed Mattermost Desktop on a fresh Ubuntu 26.04 a couple of days ago and it sat there refusing to start. Two things made this take longer than it should have. Writing it down because both are easy to walk into.

What the website tells you

Go to the Mattermost downloads page, click the Linux penguin, and the only thing on offer is a tarball:

mattermost-desktop-6.1.2-linux-x64.tar.gz

So you grab it, extract it, drop a launcher into ~/.local/bin, and double-click. Nothing happens. Run it from a terminal and you get this:

[FATAL:setuid_sandbox_host.cc:166] 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 .../chrome-sandbox is owned by root and has mode 4755.

This is an Electron sandbox helper. Distro packages (.deb, .rpm, Snap, Flatpak) all set this up in their post-install scripts. The tarball doesn't — it's just an archive of the build output. So on any Ubuntu where the kernel enforces this (which is all of them, but recent ones are stricter), the unpacked binary aborts on launch.

The fix for the tarball

Two commands:

sudo chown root:root ~/.local/opt/mattermost-desktop/chrome-sandbox
sudo chmod 4755      ~/.local/opt/mattermost-desktop/chrome-sandbox

The SUID bit is what lets the helper drop into the namespace setup the renderer needs. After this, Mattermost launches normally.

If it still won't start after that, the second thing to check on Ubuntu 24.04+ is AppArmor's restriction on unprivileged user namespaces:

sysctl kernel.apparmor_restrict_unprivileged_userns

If that's 1 and the launch still fails with a namespace-related error, you either need an AppArmor profile for the binary or to flip that sysctl. I didn't have to — the SUID fix alone was enough on 26.04 — but it's the next thing I'd check.

The .deb that actually exists

Here's the part that bugs me. A .deb package for Mattermost Desktop does exist. It's just not linked from the main downloads page. It's on GitHub releases:

https://github.com/mattermost/desktop/releases/latest

For the same 6.1.2 release that the website hands you as a tarball, the GitHub assets list also has:

The .deb runs a post-install hook that sets the SUID bit on chrome-sandbox, registers the desktop entry, and wires up the mattermost:// URL handler. Everything I had to do by hand is already done in the package.

So the install experience is currently:

  1. From the website: tarball only, no metadata, broken on launch until you fix sandbox perms manually.
  2. From GitHub releases: .deb that just works, but you have to know to look there.

It's the same upstream binary either way. It's a packaging choice that the website only links the lowest-common-denominator format and not the one that's actually painless on Debian-family distros.

What I'd suggest

If you're on Ubuntu / Debian / Mint and you want Mattermost Desktop, skip the website link. Go straight to the GitHub releases page and grab the .deb. You'll get auto-updates through apt if the upstream repo is configured (or just re-install from a newer .deb when a release shows up), and you sidestep the sandbox setup landmine entirely.

If you already installed the tarball and it's working after the chown/chmod above, there's no urgent reason to switch — the binary is the same. The only ongoing cost is that updates are manual: download a new tarball, extract, redo the SUID fix, repeat. With the .deb, apt handles it.

Why this is worth a post

The friction here isn't unique to Mattermost — it's the general pattern of "official download page only links the format that works everywhere but works poorly anywhere." Cross-platform projects pick the tarball because it's the thing they can hand to every Linux without a per-distro pipeline. Then everyone hits the sandbox setup gap on first launch and bounces, or pastes the chown/chmod into their notes and moves on.

Twenty minutes of a confusing install on a fresh OS is the kind of thing that quietly drives people to web clients. Worth flagging both the workaround and the better-hidden package, on the chance someone else is staring at the same FATAL line right now.