Jetson Orin vs. Snap 2.70

Why your Chromium browser (and other snaps) suddenly refuse to launch—and what to do about it

Symptom: every snap you start dies with
cannot set capabilities: Operation not permitted.

Jetson Orins ship with a lean kernel that omits some security options.
Snapd 2.70, the just released version of the Ubuntu app-bundle manager, now relies on those very options. This collision strands users without a working Chromium browser, and affects other apps.

This article:

1. Gives fast work-arounds to get Chromium/Firefox back on screen.
2. Explains why snap 2.70 broke things.
3. Shows the proper kernel fix.

TL;DR — quickest path for non-experts

Revert Snap

sudo snap revert snapd
sudo snap refresh --hold snapd

Preferred Work Around

Here’s my preferred work around (from @rsazid99 in the NVIDIA forums). This will download Snap 2.68.5, install it, and mark it to “hold”. Hold means that it won’t update, through either Snap or Apt.

snap download snapd --revision=24724
sudo snap ack snapd_24724.assert
sudo snap install snapd_24724.snap
sudo snap refresh --hold snapd

Flatpak route (safe on fresh flashes)

Flatpak is an alternate application manager.

$ sudo apt update && sudo apt install flatpak
$ flatpak remote-add --if-not-exists flathub
$ https://dl.flathub.org/repo/flathub.flatpakrepo
# reboot
$ flatpak install flathub org.chromium.Chromium

Why Chromium and other apps broke

Here is the NVIDIA Jetson Forum ‘Browser Issue‘ thread. It goes through the hunt to figure out why browsers quit working. I found it out was because of an update to Snap.

Snap 2.70 (snapd) ditched its old set-UID root helper and now depends on file capabilities baked into each snap’s SquashFS image. The stock Jetson Orin kernel lacks CONFIG_SQUASHFS_XATTR, the option that lets the kernel read those capability bits. When Chromium (or any snap) launches, the kernel can’t see the required privileges and aborts with: cannot set capabilities: Operation not permitted

Enabling SQUASHFS_XATTR—and ideally AppArmor with the Linux Security Manager (LSM)—lets the kernel honour the new capability model and the apps start normally.

What is a Snap, anyway?

A snap is Canonical’s “app-as-image” format: one read-only SquashFS file that contains the application and every library it needs. When you install a snap, nothing is extracted into /usr; snapd simply mounts that image at
/snap/<name>/<revision> and adds it to your $PATH.

Because each revision is just another mount point, installs, rollbacks, and removals are instant and atomic. Updates can arrive through snapd (not APT) several times a day, so a single build of Chromium—or any app—runs unchanged on every supported Ubuntu release, including Jetson.

You may have noticed if you ‘apt install chromium’ Ubuntu does not use APT to install it. Instead it redirects installation to snap.

Snaps in a nutshell — image, mount, run

snapd: package manager & runtime supervisor
snapd fetches signed revisions, mounts them, and silently auto-updates itself and every snap several times a day.
When you launch a snap, snap-confine:

1. Builds a private mount namespace so the app sees its own /usr, /lib, etc.
2. Applies sandboxing via the kernel’s LSM hooks (AppArmor on mainstream Ubuntu, seccomp & cgroups everywhere).
3. execs the real application inside that jail.

On stock Jetson kernels, AppArmor isn’t compiled in, so snap-confine falls back to a lighter seccomp-only sandbox—fine for some snaps, problematic for others once snapd 2.70 starts relying on file capabilities stored in the SquashFS image.

Why so many Ubuntu desktop apps are now snaps

Over the past few LTS cycles Canonical has migrated flagship desktop packages—Chromium, Firefox, IntelliJ, VS Code, even some GNOME utilities—into snaps by default. The goal is to solve three chronic headaches:

1. Version drift across Ubuntu releases
   Users on 20.04, 22.04, and 24.04 all want the same up-to-date browser—but the .deb repositories for those releases freeze at different points in time. A single snap build runs on every supported release (and on Ubuntu Core or IoT images) because it ships its own libraries.
2. Rapid security fixes without OS upgrades
   Because snaps live outside the traditional APT cadence, Canonical can push a critical Firefox or Chromium patch the moment it’s published, rather than waiting for each distro series to build, test, and stage a new .deb.
3. Built-in sandboxing and transactional updates
   Each snap installs atomically (it’s just a read-only mount), rolls back in one command, and runs under AppArmor/seccomp confinement. That containment layer is on regardless of whether the underlying system is strictly hardened—something plain .deb packages can’t guarantee.

For Canonical, shipping mainstream apps as snaps means one build pipeline, one store, and one auto-update mechanism that spans desktop, server, and embedded images—freeing the deb archives to focus on the core OS and libraries while snaps handle the fast-moving application layer.

Runtime sandboxing (and why AppArmor usually matters)

Before a snap even starts, the Linux kernel’s LSM (Linux Security Modules) framework asks: which security policy should I enforce?
LSM provides hook points; individual engines—AppArmor (alternatives: SELinux, Smack)—plug in and decide, on every syscall, whether to allow it.

AppArmor is Ubuntu’s preferred LSM.

• On mainstream Ubuntu it’s enabled by default with human-readable, path-based profiles.
• Jetson kernels differ: NVIDIA compiles them without AppArmor to stay lean. Hooks exist, but no policy engine is active.
• Chromium reality check: In testing, the strict-confinement Chromium snap did launch without AppArmor once the kernel could read file capabilities via CONFIG_SQUASHFS_XATTR. Snap-confine simply fell back to a seccomp-only sandbox.
• Other snaps may be less forgiving Some packages refuse to run (or drop to devmode) when no LSM is active, losing path-level file controls.

Launch sequence

1. You run chromium.
2. **snap-confine** starts.
3. It creates a private mount namespace and bind-mounts the snap’s SquashFS so the app sees its own /usr, /lib, etc.
4. It tries to load the AppArmor profile.

• If AppArmor is active, the profile applies.
• If not (stock Jetson), it skips straight to seccomp + cgroups.

It execs the real chromium binary inside that reduced sandbox.

Bottom line: CONFIG_SQUASHFS_XATTR + capabilities are enough to start Chromium, but enabling CONFIG_SECURITY_APPARMOR restores full confinement and covers snaps that insist on an LSM.

Why snap 2.70 changed everything

Snapd 2.70 removed the set-UID root bit from snap-confine.
Instead, the helper carries a tiny set of file capabilities (e.g., cap_sys_admin, cap_setuid).
On exec the kernel grants only those slices of privilege, slashing the amount of permanently-elevated code.

Enter Linux capabilities

Linux splits all-powerful root into ~40 fine-grained pieces (raw sockets, module loading, …).
An executable’s capabilities live in an extended attribute (security.capability) on the file; the kernel re-assembles them automatically when the binary runs. This lets projects like snapd ditch set-UID binaries while still granting the exact privileges required.

Why SQUASHFS_XATTR must be enabled

Because snaps are read-only SquashFS images, the kernel has to read extended attributes from that filesystem.
CONFIG_SQUASHFS_XATTR does exactly that. Without it, capabilities recorded during build disappear after the image is mounted, and you get: cannot set capabilities: Operation not permitted

Enabling SQUASHFS_XATTR together with CONFIG_SECURITY_FILE_CAPABILITIES lets snap-confine run with its minimal capability set.

⚠️ Canonical’s position on snap updates

Snapd auto-updates itself and every snap multiple times a day via its own mechanism (outside APT).
Users can revert only to the immediately previous revision still cached locally (snap revert …). Broader roll-backs are reserved for emergency channels Canonical pushes; there is no supported “turn updates off” switch.

Permanent kernel-rebuild fix

If you are doing production work, or simply want a system that isn’t a stop gap, you will need to build a custom Linux kernel with the following flags enabled at a minimum :

• CONFIG_SECURITY_APPARMOR=y
• CONFIG_SQUASHFS_XATTR=y
• (CONFIG_SECURITY_FILE_CAPABILITIES selects itself.)

You will also need to APPEND to the /boot/extlinux/extlinux.conf command line:

• apparmor=1 security=apparmor

You can then build the kernel on the device or use the official NVIDIA Jetson kernel building procedures (recommended if you are building production systems).