--mount is not compliant with Docker Desktop, results in error about orbstack HOT 4 CLOSED

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

from orbstack.

@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.

from orbstack.

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 ?

from orbstack.

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 !

from orbstack.