x11docker ERROR: waitforlogentry(): dockerrc: Timeout waiting for entry "xinitrc is ready" in xinit.log

[ItzDerock]

I'm running the following command:
x11docker -v -g -- -v "/mnt/d/Code/! Projects/MobileReplays.LOL/Container/Game/Versions/v11.11/en":/Game -v "/mnt/d/Code/\! Projects/MobileReplays.LOL/Container/Test":/Replays -- mobilereplays

The host machine is running Windows 10 Pro with Docker Desktop in WSL2 mode. The command was executed in Ubuntu 18.04 in WSL2.

Full logs can be found here.

[mviereck]

I am not exactly sure what is going wrong. Maybe the Windows firewall prevents the X server from starting. Compare https://github.com/mviereck/x11docker/wiki/x11docker-on-MS-Windows#troubleshooting

Does runx --desktop show a window?

[ItzDerock]

Manually adding VxCsrv and XLaunch to the allowed applications on Windows Firewall fixed it.
One tiny nit picky bug is that the terminal output for the -i option is strangely formatted, making it difficult to read. https://img.derock.dev/xY6PlW.png

[mviereck]

Manually adding VxCsrv and XLaunch to the allowed applications on Windows Firewall fixed it.

Good! (For x11docker you would not need to allow XLaunch but VcXsrv only.)

One tiny nit picky bug is that the terminal output for the -i option is strangely formatted, making it difficult to read. https://img.derock.dev/xY6PlW.png

Do you get a well formatted output with e.g. docker run --rm -ti alpine sh?

[ItzDerock]

Running docker run --rm -ti alpine sh works fine.
Running x11docker -vi alpine shows the incorrect formatting.
Not sure if this is intended behavior, but running without the v flag never attaches me to the shell.

Edit: I also tried using the Windows Terminal and the default WSL2 application, and the issue seems to persist onto that too. This entire time I've been using Visual Studio Code's integrated terminal, and I thought maybe that was messing with the formatting, but after some tests, this does not seem to be the case.
An intresting behavior I saw on the default WSL2 application is that it changed the font from this to this

Oh and I should probably add that I'm using WSLG which is WSl2 with native gui application support, and doesn't seem like it should be messing with the format.

[ItzDerock]

Would also like to mention that when not using the --user=root flag, the home directory for the user is not owned by the user, which prevents applications like wine from operating.

wine: '/home/derock' is not owned by you, refusing to create a configuration directory there

[ItzDerock]

Lastly, not sure if this is an x11docker issue, or a misconfiguration on my end, but with the --hostipc flag, MIT-SHM seems to still fail to function.
Xlib: extension "MIT-SHM" missing on display "192.168.1.87:2581"

[mviereck]

Thank you for reporting! What a mess ...

Running x11docker -vi alpine shows the incorrect formatting.
Not sure if this is intended behavior, but running without the v flag never attaches me to the shell.

You need to specify an interactive command like sh, otherwise you won't get a prompt.
It is ugly but normal behaviour that the -v output becomes misformated along with -i.
But nonetheless, here is a serious issue, the current behaviour is broken. I've spend a few hours yet and could not fix it so far. Will try further.
The -v flag shows the container output in the logfile, so by accident it helps to show the interactive output. But the desired workflow is without -v and having a regular prompt and regular formating.

but with the --hostipc flag, MIT-SHM seems to still fail to function.
Xlib: extension "MIT-SHM" missing on display "192.168.1.87:2581"

This is because VcXsrv runs outside of WSL and cannot share the linux namespace of WSL.

An intresting behavior I saw on the default WSL2 application is that it changed the font from this to this

That was reported once by @eine, too. The odd thing is that the font changes already before one line of x11docker is executed, likely during bash reads in the script. No idea what to do about this. As long as it is still readable I don't search further for a fix.

Would also like to mention that when not using the --user=root flag, the home directory for the user is not owned by the user, which prevents applications like wine from operating.

It should work with option --cap-default, I'll update the documentation for x11docker/lxde-wine.
The folder is owned by root but allows r/w access for everyone (chmod 777). But wine complains about this.
The issue should not happen with option --home, in that case the folder is owned by the user.

[mviereck]

A temporary workaround:
--interactive together with --no-setup works.

[mviereck]

--interactive is fixed finally. :-)

As often, it was a rather stupid bug ... Some time ago I've changed the container output redirection and forgot to regard --interactive where the output must not be redirected.

[mviereck]

Oh and I should probably add that I'm using WSLG which is WSl2 with native gui application support, and doesn't seem like it should be messing with the format.

Out of curiosity:
Could you show me the output in WLSG?

echo $DISPLAY
echo $XAUTHORITY
xhost

x11docker might run in WSLG with option --hostdisplay.

[ItzDerock]

https://img.derock.dev/2CSC7h.png

[mviereck]

Thank you for the output!
So WSLG disables all X authentication and allows access for everyone. Using runx like x11docker does is a better setup in aspects of security.