Display forwarding from docker container

[ilinojkovic]

How to set up remote display forwarding from Docker container?

Currently, my .devcontainer contains:

devcontainer.json

{
	"name": "kinetic_v5",
	"context": "..",
	"dockerFile": "Dockerfile",
	"workspaceFolder": "/workspace",
	"runArgs": [
		"--net", "host",
		"-e", "DISPLAY=${env:DISPLAY}",
		"-e", "QT_GRAPHICSSYSTEM=native",
		"-e", "CONTAINER_NAME=kinetic_v5",
		"-v", "/tmp/.X11-unix:/tmp/.X11-unix",
		"--device=/dev/dri:/dev/dri",
		"--name=kinetic_v5",
	],
	"extensions": [
		"ms-python.python"
	]
}

Dockerfile

FROM docker.is.localnet:5000/amd/official:16.04

RUN apt-get update && \
    apt-get install -y zsh \
    fonts-powerline \
    locales \
    # set up locale
    && locale-gen en_US.UTF-8

RUN pip install Cython

# run the installation script  
RUN wget https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | zsh || true

CMD ["zsh"]

This doesn't seem to do the job.

Setup details:

• OS: linux
• Product: Visual Studio Code - Insiders
• Product Version: 1.35.0-insider
• Language: en

I already asked this on stackoverflow, but no response there.

[chrmarti]

For which application do you want to forward the display? How do you start it?

[ilinojkovic]

I'm running a mujoco simulation inside a docker container, and in some cases would like to visualize the simulation. I'm using the official c++ api which uses glfw to create the window.

[chrmarti]

This seems to be an issue independent of VS Code's Remote Containers. Do you have this working just with Docker?

[ilinojkovic]

Yes. I used this script which worked fine:

#!/bin/bash
xhost +local:
VERSION=$"3"
docker run -it --net=host \
  -u=$(id -u) \
  -e DISPLAY=$DISPLAY \
  -e QT_GRAPHICSSYSTEM=native \
  -e CONTAINER_NAME=kinetic_v${VERSION} \
  -e USER=$USER \
  --workdir=/absolute_path_to/workspace \
  -v "/tmp/.X11-unix:/tmp/.X11-unix" \
  -v "/etc/group:/etc/group:ro" \
  -v "/etc/passwd:/etc/passwd:ro" \
  -v "/etc/shadow:/etc/shadow:ro" \
  -v "/etc/sudoers.d:/etc/sudoers.d:ro" \
  -v "/home/$USER/:/home/$USER/" \
  --device=/dev/dri:/dev/dri \
  --name=kinetic_v${VERSION} \
  ilinojkovic/ros:kinetic_v${VERSION}

When I move all these arguments into runArgs, I cannot get it to connect/bind the display.

[ishouldbedany]

Hi. Code user here in a similar situation.

I followed up with @ilinojkovic via email and we reached the conclusion that X11 forwarding works with the following runArgs in .devcontainer.json:

"runArgs": [
        "--net", "host", 
        "-e", "DISPLAY=${env:DISPLAY}",
        "-v", "/tmp/.X11-unix:/tmp/.X11-unix"
],

Some of the lines in his original setup were messing things up. As extra info, I am logging as a root user (at least in my case).

Regardless of this having worked, I think it would be positive to add some documentation on how to achieve this and/or ease the workflow.

For image/video applications (think OpenCV, VTK, PCL, Kinect, ROS, etc, which are all dependency hell) or even basic Data Science environments (interactive matplotlib plots, for instance - I know the Jupyter cell mode exists in VS Code, but interactivity there is essential), having access to the native windows is critical.

I image that as VS Code Remote gets more popular and some of these complex frameworks start to consider offering its development environments through containers, this request will become increasingly popular.

Also taking the opportunity to thank you for an incredible piece of software. It's stellar! 👍 👍

[chrmarti]

Great, thanks @ishouldbedany @ilinojkovic !

@Chuxel Is X11 forwarding something you would want to include in our documentation? (See above comment.)

[Chuxel]

@chrmarti Yeah #616 is the same doc suggestion and I got it working both on Windows (via VcXsrv) and macOS - it uses a slightly different model that works for Windows too. I can take the to-do to doc it.

[ilinojkovic]

Just as a follow up, the issue was solved with the modification from @ishouldbedany's comment, but then reappeared. In the meantime, I updated os packages and vs-code itself, so I don't know if that's somehow connected. I rebuilt the image, but the error persisted.

[ishouldbedany]

I have a fully updated Ubuntu 18.04 LTS as a host and VS Code 1.35.1. Working normally for me.

[ishouldbedany]

Update: I'm having the same issue in one of the containers I have with X-forwarding enabled. On another one I have, everything is working normally (with the same configuration).

I also did some minor OS upgrades, but nothing major, it came very out of the blue. I also rebuilt the image, no luck.

I am not sure what's causing this and my knowledge of the Linux desktop stack is limited at best. Happy to provide further info and help debugging.

[ishouldbedany]

Update on my update: I manged to get it working again by running, on the host system, the command at the start of @ilinojkovic's initial script:

xhost +local:

The solution (with some follow-up discussions on security) is available here: jessfraz/dockerfiles#6

This instruction seems to be reset everytime the X server is restarted, hence why this method is working intermittently.

[Chuxel]

Just to update the thread, the reason this hasn't been added to docs yet is it is a bit tricky to get working particularly on macOS. We looked at doing this for Microsoft/vscode, but held off because of these issues. More details here:

https://github.com/microsoft/vscode/issues/82060#issuecomment-542431498

It all works, but I'm less confident in documenting it as a "supported scenario" at the moment. UI perf was also pretty bad, but part of that may be due to the lack of access to GPU acceleration on Windows/macOS.

[dhartaifb]

I realize this topic is pretty old but I am working on something similar. In the docker container on a remote host a mujoco simulation should be x11 forwarded to my local windows machine with visual studio code. Everything I tried wasn't working with the runArgs in this topic. Anyone can help or point me in the right direction?

[chrmarti]

Implementing X11 forwarding as a new feature. We will also mount the Wayland socket if there is a local one (that is difficult to forward across the network because it relies on shared memory).

[chrmarti]

Published with Dev Containers 0.269.0-pre-release.

FYI @davidwallacejackson: X11 forwarding implemented here can serve as a lighter weight alternative to VNC.

[davidwallacejackson]

Published with Dev Containers 0.269.0-pre-release.

FYI @davidwallacejackson: X11 forwarding implemented here can serve as a lighter weight alternative to VNC.

Thank you for the heads up! I look forward to giving it a shot.

[patrick-5546]

Even with the prerelease DISPLAY is still being set incorrectly in my dev container:

• With release version 0.266.1, DISPLAY is 1
• With pre-release version 0.269.0, DISPLAY is :1

I also spotted this error in the Dev Containers log, not sure if it's related:

Container server: Error: listen EROFS: read-only file system /tmp/.X11-unix/X1
    at Server.setupListenHandle [as _listen2] (node:net:1313:21)
    at listenInCluster (node:net:1378:12)
    at Server.listen (node:net:1476:5)
    at /tmp/vscode-remote-containers-server-d83c77f335bbac30d8199ed4da8cedec8829dad7.js:12:9517
    at new Promise (<anonymous>)
    at /tmp/vscode-remote-containers-server-d83c77f335bbac30d8199ed4da8cedec8829dad7.js:12:9500
    at async Promise.all (index 1)

Related issues:

• DISPLAY env does not get set correctly in container #7565

[chrmarti]

@patrick-5546 :1 is the correct value. It seems your container's /tmp folder is read-only? (It tries to listen on a socket path for that display.)

[patrick-5546]

@chrmarti the value of DISPLAY outside the dev container is :0. Display forwarding doesn't work when DISPLAY is :1 inside the dev container, but it does when DISPLAY is :0.

Also, /tmp.X11-unix is mounted as read-only in WSL so the error is expected.

[chrmarti]

It can be a different display number inside the container than outside. The error refers to a path inside the container /tmp/.X11-unix/X1. Do you mount WSL's /tmp in the container?

[patrick-5546]

@chrmarti yes I used the runArgs recommended in one of the comments above:

"runArgs": [
        "--net", "host", 
        "-e", "DISPLAY=${env:DISPLAY}",
        "-v", "/tmp/.X11-unix:/tmp/.X11-unix"
],

I even tried "-v", "/tmp/.X11-unix:/tmp/.X11-unix:rw", but still get the same error.

Another thing I noticed is that /tmp/.X11-unix/X1 doesn't even exist in WSL or the dev container: there is only /tmp/.X11-unix/X0, which is not read-only:

$ ls -l /tmp/.X11-unix/X0
srwxrwxrwx 1 <user> <user> 0 Jan 25 06:07 /tmp/.X11-unix/X0

[connor4312]

This is cool, it ✨ just works ✨ for me on Ubuntu.

[chrmarti]

@patrick-5546 Could you try without mounting /tmp/.X11-unix and without setting DISPLAY? This should all be done automatically in the latest Dev Container pre-releases (currently 0.273.0-pre-release).

[patrick-5546]

@patrick-5546 Could you try without mounting /tmp/.X11-unix and without setting DISPLAY? This should all be done automatically in the latest Dev Container pre-releases (currently 0.273.0-pre-release).

@chrmarti DISPLAY was set properly and the error disappeared after doing this, thanks for the help!

Side note, my pre-release version is stuck at 0.269.0. When I click "switch to pre-release version" I see v0.273.0, but after reloading VS Code I see v0.269.0.

[chrmarti]

@patrick-5546 The latest pre-releases require VS Code Insiders 1.75. VS Code 1.75 stable is expected later this week, so you could switch to Insiders or just wait for the 1.75 release.

[midsorbet]

The Insiders Build works great on M1 Mac with XQuartz

[bhack]

@chrmarti Was this tested on docker rootless? As also on insiders I still need xhost + on the host.

[chrmarti]

@bhack That might also be needed with Docker running rootful?

[bhack]

@bhack That might also be needed with Docker running rootful?

It seems it was not required in rootless:

https://unix.stackexchange.com/a/685514

Also, what is the case on modern desktop for Wayland?
Are we already going to support Wayland?

https://unix.stackexchange.com/questions/330366/how-can-i-run-a-graphical-application-in-a-container-under-wayland

[chrmarti]

I guess whether or not you'll need to grant permissions with xhost + depends on your local setup. Do you think there is something we could do to improve it? Automatically running xhost + might be too permissive I assume.

Wayland should work when the Wayland socket is on the same machine as the Docker daemon. We have tested this with WSL on Windows, would be interesting to get feedback for other setups. (Wayland uses shared memory, so we can't forward it across the network like we can with X11.)

[bhack]

Also in this old red hat issue it seems to confirm that xhost is not required. Are we missing something?

https://bugzilla.redhat.com/show_bug.cgi?id=1895287

[chrmarti]

I should add: The connection to the display's socket path is initiated locally. We listen on a socket path in the container and then forward connections to the local host where we connect to the display's socket path.