Hardware Platform: Jetson orin nano dev kit - 8GB
DeepStream Version: 7.1
JetPack Version: 6.2
TensorRT Version: 10.3.0.30
CUDA: 12.6.68
This problem is observed on two separate Jetson Orin Nano dev kits.
Both devices were functioning normally, including browsers (Chromium, Firefox, and Brave), until an automatic system update occurred during startup, before the user login GUI.
After this auto update process, none of the browsers will launch. Attempting to open them results in no response.
Launching Chromium via terminal with Snap produces the following logs:
snap run chromium
2025/07/10 13:35:10.644806 cmd_run.go:1344: WARNING: cannot create user data directory: failed to verify SELinux context of /home/test/snap: exec: “matchpathcon”: executable file not found in $PATH
cannot set capabilities: Operation not permitted
This exact behavior is consistent across both boards and occurs only after the automatic update.
Given that this issue appeared on two different Jetson Orin Nano boards immediately after the auto update, and it affects multiple browsers installed via Snap, it suggests that the problem could be related to a bug or misconfiguration in the Snap packages or Snapd service itself.
Today the same error led me to this post. Chromium and Pycharm stopped running, but Pycharm can still be launched via the terminal. The links on the desktop originally installed with the package also do not work.
2025/07/10 16:40:55.770902 cmd_run.go:1344: WARNING: cannot create user data dir ectory: failed to verify SELinux context of /home/darkhan/snap: exec: “matchpathcon”: executable file not found in $PATH cannot set capabilities: Operation not permitted
same issue on orin agx 64gb. I tried installing or disabling selinux, purging and reinstalling the browser from snap, but of course nothing worked.
what msalazar suggests works for me for chromium (not firefox though)
EDIT following day: today chromium doesn’t start and gives the blank page, as other people below
Unfortunately, I ran into the same blank window the first time I encountered this issue. But after re-flashing and encountering the issue again, it just started working as expected with the --no-sandbox flag.
At this point I would just wait for a response from support. I wish I could help more, sorry.
I’m getting the same error this morning. Chromium won’t work without the sudo --no-sandbox. Posting here so that I can keep track if there are any other fixes.
I can’t answer, but here is a related observation: Jetsons do not normally enable SElinux. The filesystem does not even have the SElinux labels in most cases. For chromium, the --no-sandbox is related to trying to use (or not use) SElinux labels. I’m going to guess and say one of the updates enabled something regarding SElinux (which desktop PC versions of Linux “often” do add by default).
Assuming the o/s itself is not trying to enforce labels, then it comes down to providing an option to the application (such as chromium) to not use SElinux labels.
Same issues here but it is more than just browsers. Multiple different applications fail to run and give the same error as others posted above. At first I thought it was a SELINUX issue and tried to disable it but many of the SELINUX commands (sestatus) for example aren’t present on the fresh install. So not sure where to go with this one.
It appears to be an issue with snap. I’m investigating adding the CONFIG_SECURITY_APPARMOR=Y ; if you
$ SNAPD_DEBUG=1 SNAP_CONFINE_DEBUG=1 /snap/bin/chromium
You’ll see that it’s trying to use Apparmor which is not enabled in the default distribution kernel.
Yesterday(10 July 25) i had the same problem with two of my Orin nano boards. I just went for a tea break and came, the browsers were not opening thereafter which i was using seamlessly earlier. **I tried reflashing but still the issue persists! No browsers are working! I have spend considerable time on this issue analyzing and board reflashing.
It is a snap permissions issue. With the Snap 2.70+ change, snap-confineno 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.
