Skip to main content


Jetson Nano: Capabilities fail to start


The latest Jetpack version available for Jetson Nano's does not permit the creation of overlayfs' inside a unshare -rm environment, which causes capabilities to fail to start. The log will say something like:

using unshare -r
preparing sandbox for @transitive-robotics/foxglove-webrtc (robot)
mount: /home/robot/.transitive/tmp/tmp.gJHqvyLkRF/usr/merged: permission denied.
mount: /home/robot/.transitive/tmp/tmp.gJHqvyLkRF/opt/merged: permission denied.


Grant the user you are using to install and run the Transitive agent password-less sudo (by adding USERNAME ALL = NOPASSWD: ALL to /etc/sudoers using visudo, where USERNAME is your username). Alternatively you can run Transitive in Docker.

Encrypted home-folder

If your home directory is encrypted, the overlayfs' Transitive uses to sandbox its capabilities will fail.


If mount | grep $HOME | grep ecryptfs returns anything, then your home folder is encrypted.


Create a folder on an unencrypted filesystem anywhere else on your system (e.g., /home/$USER_unencrypted), then sym-link it to ~/.transitive (e.g., ln -s /home/$USER_unencrypted ~/.transitive). Then reinstall the Transitive agent in the newly created folder.

The device doesn't show up in the Transitive Portal

There can be several reasons for this, but most of the time it's a restriction on the network to connect to port 8883 on our cloud instance.



curl -m 3

When the port is working you will see

curl: (56) Recv failure: Connection reset by peer

If it is not working, it will be something like:

curl: (7) Failed to connect to port 8883: Connection timed out


Talk to your network admin, which often is the IT staff of the customer where your robots are deployed, and request that they permit all traffic to (or when self-hosting your own cloud instance), but for the very least permit port 8883.