ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

ROS2: rviz in docker container

asked 2018-08-20 15:11:53 -0500

alsora gravatar image

updated 2018-08-20 20:08:51 -0500

jayess gravatar image


I'm trying to use Rviz2 from within a Docker container.

I'm working on top of this Docker image

FROM osrf/ros2:bouncy-desktop

This is my run script



touch $XAUTH

xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -

docker run -it --rm \
 -v $XSOCK:$XSOCK:rw \
 -v $XAUTH:$XAUTH:rw \
 ros2_docker \

Everything works fine, but then I needed to make the Docker container communicate with other machines on the host network. I accomplished that by adding the following option to docker run --net=host \

This solves the connectivity issue, but has the side effect of making rviz not working anymore. If I try to run rviz, I only get the following error.

 ros2 run rviz2 rviz2

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
dbus[1041]: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.
Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection.
  D-Bus not built with -rdynamic so unable to print a backtrace

Any idea about how to fix this? Thanks

edit retag flag offensive close merge delete


That's peculiar. I'm using nvidia docker, yet I can reproduce your rviz(1 or 2) XDG_RUNTIME_DIR error when adding --net=host for both melodic and bouncy images.

ruffsl gravatar image ruffsl  ( 2018-08-20 16:10:05 -0500 )edit

XDG_RUNTIME_DIR doesn't seem to be necessary the issue, given it otherwise would normally default to something like '/tmp/runtime-root'. The privilege issue with managing the dbus connection seem to be the setback here.

ruffsl gravatar image ruffsl  ( 2018-08-20 16:31:06 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2018-08-20 16:22:20 -0500

ruffsl gravatar image

updated 2018-08-20 16:27:56 -0500

I'm not yet totally sure yet as to why, but it appears that using the host network driver then necessitates adding the privileged flag if one also wishes to use the host's X11 unix socket simultaneously. I.e. just add --privileged upon using --net=host with the docker run command when expecting to forward containerised GUIs to the host's X11 display.

A small example I used to check this:


FROM osrf/ros2:bouncy-desktop

# nvidia-container-runtime




docker run -it --rm \
 --runtime=nvidia \
 -v $HOME/.Xauthority:/root/.Xauthority \
 --privileged \
 --net=host \
 osrf/ros2:bouncy-desktop-nvidia "$@"


docker build -t osrf/ros2:bouncy-desktop-nvidia .
bash run.bash ros2 run rviz2 rviz2

Note that if you're not using nvidia, you can use intel's embedded graphics just as well instead:

edit flag offensive delete link more


@ruffsl - did you ever figure out why --privileged was needed in this case? We use --net=host and we see gazebo, rviz, and rqt fail with that same dbus error message unless we use the --privilegedflag. I'd like to avoid running containers in privileged mode if at all possible, but i haven't yet found another workaround. This feels potentially related to , but we're on a much newer version of docker now (19.03.8)

jbinney gravatar image jbinney  ( 2020-05-11 17:06:46 -0500 )edit

Update: i managed to workaround the problem by downloading the newest docker seccomp config from and passing it to "docker run" using " --security-opt seccomp=/path/to/config.json". See

This seems preferable to running with "--privilieged"

jbinney gravatar image jbinney  ( 2020-05-11 18:48:06 -0500 )edit

Update to the update: i was wrong... that didn't fix it.

jbinney gravatar image jbinney  ( 2020-05-11 19:50:46 -0500 )edit

Ah! It was (at least for me) a problem with the default apparmor profile blocking that dbus call. Adding "--security-opt apparmor:unconfined" works, and seems better than "--privileged". This seems to be the issue:

Hopefully docker/apparmor and qt sync up on this in 20.04 so that the default apparmor profile allows running QT apps in docker more easily.

jbinney gravatar image jbinney  ( 2020-05-12 01:02:45 -0500 )edit

Wow, that's a deep rabbit hole. Still looks like a pain to patch and document everyware. Is this still needed for Ubuntu 20.04, or have you not gotten around to trying it out on the latest distro?

ruffsl gravatar image ruffsl  ( 2020-05-14 00:54:40 -0500 )edit

@ruffsl i haven't tried 20.04 yet - I'll update this issue when i do (might be a while)

jbinney gravatar image jbinney  ( 2020-05-14 17:22:09 -0500 )edit

@jbinney, what are you running as the host. I can run rocker --nvidia --x11 --network host osrf/ros2:nightly 'bash -c ". /opt/ros/foxy/setup.bash && rviz2"' successfully

which runs docker run -it --rm --network host --gpus all -e DISPLAY -e TERM -e QT_X11_NO_MITSHM=1 -e XAUTHORITY=/tmp/.docker.xauth -v /tmp/.docker.xauth:/tmp/.docker.xauth -v /tmp/.X11-unix:/tmp/.X11-unix -v /etc/localtime:/etc/localtime:ro cdfc90f87eb4 bash -c ". /opt/ros/foxy/setup.bash && rviz2"

With a host of 18.04

tfoote gravatar image tfoote  ( 2020-05-14 17:36:11 -0500 )edit

@jbinney repeated all you step to start the container, still same error exist. I am using a non-root user (id 1000).

ThomasL624 gravatar image ThomasL624  ( 2022-11-28 22:11:39 -0500 )edit

Question Tools



Asked: 2018-08-20 15:11:53 -0500

Seen: 11,490 times

Last updated: Aug 20 '18