It is a snap permissions issue. With the Snap 2.70+ change, snap-confine no longer needs to be setuid root , and instead relies on file capabilities , executing in the security context of the invoking user .
| Change | Effect |
|---|---|
snap-confine is no longer setuid |
Runs with user’s privileges, not root |
Uses file capabilities like cap_sys_admin or cap_setuid |
More granular, but vulnerable to permission issues |
| Snap sandbox is now bootstrap-dependent on correct user context | If user can’t access $HOME, Snap fails early |
| AppArmor now enforced earlier | Blocks $HOME, dbus, or other mounts before namespace forms |
Bind-mounting snap-confine now breaks expected behavior |
Because user is missing the necessary capabilities |
| What used to be a root-launched bootstrapper is now a user-context-sensitive sandbox tool. Snap has essentially “moved the trust boundary downward.” |
That makes sense for:
- Multi-user systems
- Security auditing
- Fine-grained control
But for edge systems like Jetson or embedded boards, this increases fragility, especially if:
- You’re customizing kernel builds (AppArmor might be off)
- Home directories have unusual permissions
- Snap core updates silently (which they do)
I was able to get it running properly by enabling Apparmor (CONFIG_SECURITY_APPARMOR) in the kernel. You also have to add APPEND apparmor=1 security=apparmor to the kernel parameters. Apparmor is built into the Image; it’s more than just adding a module. You will also need to enable CONFIG_SQUASHFX_XATTR to make sure that snap can set capabilities.
I haven’t been able to figure out if you have to have Apparmor enabled (my guess is that you do), so I’ll have to play with it some to figure out the minimum requirement to get it up and running again. BTW, this effects everything installed by a snap, it’s not just Chromium.
While I was able to get it up and running, I still need to untangle what I did during development. Apparmor seems to be a little finicky on when and how it builds rules for installation.