--mount is not compliant with Docker Desktop, results in error

[nheuillet]

Describe the bug
Using --mount instead of -v results in an error.
This error was discovered while trying to run GUI apps within containers. Mounting the x11 sock using -v works, but doing so with --mount does not.

To Reproduce
Steps to reproduce the behavior:

1. Run docker run -it --env="DISPLAY=host.docker.internal:0" -v /tmp/.X11-unix:/tmp/.X11-unix:rw ubuntu
2. Notice that container creation does work, and any app can be launched (in my case, I tested using firefox) XQuartz is needed
3. Run docker run --rm --name tmp -it --mount 'type=bind,src=/tmp/.X11-unix,dst=/tmp/.X11-unix' debian bash
4. Notice that it results in an error.

Do note that those two commands work in Docker Desktop

Expected behavior
--mount working like in Docker Desktop

Screenshots

Logs
N/A

System info

• macOS version: Ventura 13.1 (22C65)
• CPU architecture: Intel (x86), but the problem has been confirmed also on Apple Silicon (ARM - M1/M2)

Additional context
This is the root cause for this exchange we had on Mastodon
This issue was first opened on Exegol

[kdrag0n]

This root cause is that /tmp is referring to a Linux tmpfs here, not the macOS one which is actually a symlink to /private/tmp. I've fixed /tmp mounting for the next version.

Neither OrbStack nor Docker Desktop supports forwarding Unix sockets through bind mounts, so even if the directory is mounted correctly, you can't connect to the socket. I plan to explore how feasible it would be to implement this in the future, but it's a very difficult problem (for several reasons) that can usually be worked around easily by using TCP instead.

Your first command works because -v auto-creates the source directory if it doesn't exist. It would be empty, but it still works because DISPLAY=host.docker.internal:0 makes X11 clients connect to the server over the network (TCP). The Unix socket isn't used in this case.

Unlike -v, --mount type=bind fails if the directory doesn't exist instead of creating it. The second command still wouldn't be able to run X apps, however, because you don't have DISPLAY set to the TCP host. The real Exegol environment probably works under Docker Desktop because it sets DISPLAY correctly to use TCP, so the /tmp/.X11-unix mount isn't actually doing anything functionally.

Until the next version is released, you should be able to work around the issue by removing the /tmp/.X11-unix mount.

cc @ShutdownRepo @QU35T-code @podjackel @Dramelac

[Dramelac]

Thanks you @kdrag0n for this explanation, it makes way more sense now.

I still have a last question, is the implementation of docker desktop on Windows different than the one on macOs ? Because (I would have to double check but) on Windows I manage to mount Unix socket from the WSL2 environment (the same x11 socket from WSLg), maybe WSL2 have a custom bypass / implementation ?

[nheuillet]

Very interesting read , thank you very much !
I thought I had a better understanding of the underlying issue 😅
Thanks for such reactivity. Can't wait for the next release !

[kdrag0n]

@Dramelac Mounting the WSLg socket works because the Xwayland and Wayland servers are running on the Linux side, whereas the XQuartz server is running on macOS in this case. Microsoft uses RDP to stream windows from Linux instead of passing through an X/Wayland server.