Connection to X server lost [--user=RETAIN] [--init=systemd]

[DiXN]

Ever since version 7.1.0 I cannot launch my container anymore. More specifically since commit: c99244d.

I launch my container with x11docker --clipboard --dbus --shell=/bin/zsh -I -p --desktop --user=RETAIN --cap-default --sudouser --gpu --xorg "CONTAINER"

"CONTAINER" launches the awesome window manager internally with ENTRYPOINT [ "awesome" ] and yields the following error message:

E: awesome: main:694: cannot open display (error 1)

[mviereck]

Thank you for the report!
I have fixed the issue, current master version works now.

The bug occured with --user=RETAIN; x11docker used some wrong container pathes for shared files in that case.

[DiXN]

Can confirm that it works now as expected.

I now have an issue with systemd user units using the flag --init=systemd producing the following error:

The name org.freedesktop.systemd1 was not provided by any .service file

However this might be a separate issue and unrelated to the original problem of this issue.

[mviereck]

However this might be a separate issue and unrelated to the original problem of this issue.

Yes, this looks unrelated.
Could you please open a new ticket for this, providing the logfile ~/.cache/x11docker/x11docker.log at pastebin? I recently did some changes to --init=systemd but my own tests succeeded so far.
The error message should not cause a failure, likely the issue s elsewhere.

[mviereck]

Yet found an issue in the cgroup setup for systemd and fixed it. Could you please update and test again?

[DiXN]

With --user=RETAIN and --init=systemd it crashes now.

While testing this i found another issue with --user=RETAIN where it cannot load the configuration for my windows manager. Presumably because the container user is wrong. A further hint for this is that my terminal emulator launches in /tmp/RETAIN and the environment seems wrong:

x11docker[00:28:50,980]: Container environment:
DISPLAY=:107
HOME=/tmp/RETAIN
HOSTNAME=e77232bd87bf
LANG=en_US.UTF-8
NVIDIA_DRIVER_CAPABILITIES=all
NVIDIA_VISIBLE_DEVICES=all
OLDPWD=/tmp
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PULSE_SERVER=tcp:192.168.254.1:38137
PWD=/tmp/RETAIN
SHELL=/bin/zsh
SHLVL=0
TERM=xterm
USER=RETAIN
_=/usr/sbin/env
XAUTHORITY=/x11docker/Xauthority.client
XDG_RUNTIME_DIR=/tmp/XDG_RUNTIME_DIR
XDG_SESSION_TYPE=x11

Actually querying for $HOME with echo $HOME in my shell yields the correct result though: /home/mk where mk is my image user.

[mviereck]

Thank you for the report!
I did some fixes that should resolve most, maybe all of the reported issues. Yet did not check out all of this, will look further.

[DiXN]

--user=RETAIN with and without --init=systemd seem to work now.

Therefore I tried to tackle The name org.freedesktop.systemd1 was not provided by any .service file again.

When comparing the container with my system I can see that there is no user.slice and the service user@1000 is not started. Starting the user@1000 service manually does not solve the issue either. loginctl list-users also does not return any user. At this point I don't know if this is even an issue with x11docker or just my configuration. Can you reproduce the issue with systemctl --user list-units?

[DiXN]

As an addition I now had a look at the systemd output and found that a lot of services could not be started because the cgroup ID could not be retrieved or the services could not connect to the journal which also could not be started.

Please see the full systemd startup in the following paste:
https://pastebin.com/EPvBvMrG

[mviereck]

Those errors are unusual. Maybe you need package libpam-systemd in image.
Following outputs with x11docker/check and cgroupv2. (Edit: just tested on cgroupv1, same result. Also tested with --user=RETAIN).

loginctl looks good here:

$ loginctl
SESSION  UID USER     SEAT  TTY    
     c1 1000 lauscher seat0 console

1 sessions listed.

However, I also have no user.slice or user.1000. To admit, I am not sure what they would serve for. I am no expert in systemd, just got it running in container.

$ systemctl --user list-units --all
UNIT                        LOAD   ACTIVE   SUB       DESCRIPTION                  
-.mount                     loaded active   mounted   /                            
dev-mqueue.mount            loaded active   mounted   /dev/mqueue                  
etc-hostname.mount          loaded active   mounted   /etc/hostname                
etc-hosts.mount             loaded active   mounted   /etc/hosts                   
etc-resolv.conf.mount       loaded active   mounted   /etc/resolv.conf             
proc-acpi.mount             loaded active   mounted   /proc/acpi                   
proc-asound.mount           loaded active   mounted   /proc/asound                 
proc-bus.mount              loaded active   mounted   /proc/bus                    
proc-fs.mount               loaded active   mounted   /proc/fs                     
proc-irq.mount              loaded active   mounted   /proc/irq                    
proc-kcore.mount            loaded active   mounted   /proc/kcore                  
proc-keys.mount             loaded active   mounted   /proc/keys                   
proc-sysrq\x2dtrigger.mount loaded active   mounted   /proc/sysrq-trigger          
proc-timer_list.mount       loaded active   mounted   /proc/timer_list             
sys-firmware.mount          loaded active   mounted   /sys/firmware                
tmp.mount                   loaded active   mounted   /tmp                         
var-lib-journal.mount       loaded active   mounted   /var/lib/journal             
x11docker.mount             loaded active   mounted   /x11docker                   
init.scope                  loaded active   running   System and Service Manager   
dbus.service                loaded active   running   D-Bus User Message Bus       
pulseaudio.service          loaded inactive dead      Sound Service                
-.slice                     loaded active   active    Root Slice                   
dbus.socket                 loaded active   running   D-Bus User Message Bus Socket
pulseaudio.socket           loaded active   listening Sound System                 
dev-sda3.swap               loaded active   active    /dev/sda3                    
dev-zram0.swap              loaded active   active    /dev/zram0                   
basic.target                loaded active   active    Basic System                 
default.target              loaded active   active    Default                      
paths.target                loaded active   active    Paths                        
shutdown.target             loaded inactive dead      Shutdown                     
sockets.target              loaded active   active    Sockets                      
timers.target               loaded active   active    Timers                       

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

32 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

Edit: just tried systemd --user, but it fails, even with x11docker option --cap-default:

$ systemd --user
Failed to create /user.slice/user-1000.slice/session-c1.scope/init.scope control group: Permission denied
Failed to allocate manager object: Permission denied

[DiXN]

After some further testing I found the issue.

The journal can be fixed by sharing /etc/machine-id with --share /etc/machine-id.

The name org.freedesktop.systemd1 was not provided by any .service file can resolved by executing loginctl enable-linger USER which creates the folder /run/user/1000.
This folder seems to be necessary for systemd to communicate with user units.

The environment variable XDG_RUNTIME_DIR then has to be set to XDG_RUNTIME_DIR=/run/user/1000.
By default x11docker sets XDG_RUNTIME_DIR=/tmp/XDG_RUNTIME_DIR with configuration --user=RETAIN --init=systemd

Invoking loginctl enable-linger USER and setting the proper environment can easily be done in a startup script but all this feels like a workaround, especially since loginctl still reports "No sessions".

[mviereck]

Thank you for your investigation! I'll check it out.
Did you install libpam-systemd in image?

/etc/machine-id should be created by docker (I assume) and shows some hex number different from the one on host.

The environment variable XDG_RUNTIME_DIR then has to be set to XDG_RUNTIME_DIR=/run/user/1000.
By default x11docker sets XDG_RUNTIME_DIR=/tmp/XDG_RUNTIME_DIR with configuration --user=RETAIN --init=systemd

x11docker sets XDG_RUNTIME_DIR=/tmp/XDG_RUNTIME_DIR first; when it sees that there is a folder /run/user/$(id -u), it creates a softlink from /tmp/XDG_RUNTIME_DIR to /run/user/$(id -u), so the folders are effectively the same and provide the same content.

The name org.freedesktop.systemd1 was not provided by any .service file

x11docker disabled this service. I am not sure yet why I disabled this one; x11docker disables several org.freedesktop.* services because they often cause trouble in container.

---

I've adjusted x11docker:

• set XDG_RUNTIME_DIR to /run/user/UID
• start loginctl enable-linger USER
• allow org.freedesktop.systemd1.service

[mviereck]

Invoking loginctl enable-linger USER and setting the proper environment can easily be done in a startup script but all this feels like a workaround, especially since loginctl still reports "No sessions".

In my (edited) post above I've implemented some of your suggestions in x11docker and uploaded a commit.
However, I wonder why loginctl shows no sessions in your container.

What host system and what image system do you use? What is your docker version?

Could you compare e.g. with image x11docker/check that is based on debian 10, or with x11docker/lxde that is based on debian 11?

The journal can be fixed by sharing /etc/machine-id with --share /etc/machine-id.

This is a confusing one. If you do not share, does /etc/machine-id exist and has content?
If you share, I'd recommend to mount read-only with --share /etc/machine-id:ro

Edit: x11docker now creates /etc/machine-id if it is missing or empty with dbus-uuidgen >/etc/machine-id

loginctl looks good here, should work for you, too:

$ loginctl user-status
someuser (1000)
	   Since: Wed 2022-02-23 20:35:08 CET; 6s ago
	   State: active
	Sessions: *c1
	  Linger: yes
	    Unit: user-1000.slice
		  ├─session-c1.scope
		  │ ├─1168 su - -s /bin/sh someuser /x11docker/containerrc
		  │ ├─1192 -sh /x11docker/containerrc
		  │ ├─1221 bash
		  │ ├─1235 loginctl user-status
		  │ └─1236 pager
		  └─user@1000.service
		    ├─app.slice
		    │ ├─dbus.service
		    │ │ └─1191 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile 
--systemd-activation --syslog-only
		    └─init.scope
		      ├─1182 /lib/systemd/systemd --user
		      └─1183 (sd-pam)

Feb 23 20:35:08 f7a839053e49 systemd[1182]: Reached target Basic System.
Feb 23 20:35:08 f7a839053e49 systemd[1182]: Started Multimedia Service.
Feb 23 20:35:08 f7a839053e49 systemd[1182]: Reached target Main User Target.
Feb 23 20:35:08 f7a839053e49 systemd[1182]: Startup finished in 58ms.
Feb 23 20:35:08 f7a839053e49 systemd[1182]: Started D-Bus User Message Bus.

[DiXN]

Did you install libpam-systemd in image?

In my (edited) post above I've implemented some of your suggestions in x11docker and uploaded a commit. However, I wonder why loginctl shows no sessions in your container.

What host system and what image system do you use? What is your docker version?

I am using Arch Linux with Docker version 20.10.12, build e91ed5707e for my host system and Arch Linux in my image as well. For this reason I cannot install libpam-systemd but I think that I have all the necessary dependencies for pam installed.

Could you compare e.g. with image x11docker/check that is based on debian 10, or with x11docker/lxde that is based on debian 11?

loginctl works fine here but somehow systemctl --user reports another bus issue.

In my (edited) post above I've implemented some of your suggestions in x11docker and

I don't know if they are good practice since I do not have any deeper understanding of systemd. Those suggestions are just the ones that made it work for me.

Your fixes work well in my container, however they do not change anything in regard to loginctl output.

Notice the difference in State and the absence of a session compared to your output:

loginctl user-status mk
mk (1000)
           Since: Thu 2022-02-24 04:20:30 CET; 3min 52s ago
           State: lingering
          Linger: yes
            Unit: user-1000.slice
                  └─user@1000.service
                    ├─app.slice
                    │ ├─at-spi-dbus-bus.service
                    │ │ ├─2065 /usr/lib/at-spi-bus-launcher
                    │ │ ├─2071 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
                    │ │ └─2083 /usr/lib/at-spi2-registryd --use-gnome-session
                    │ ├─dbus.service
                    │ │ └─1868 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
                    │ └─gvfs-daemon.service
                    │   └─1878 /usr/lib/gvfsd
                    └─init.scope
                      ├─1833 /usr/lib/systemd/systemd --user
                      └─1839 "(sd-pam)"

Feb 24 04:20:30 5d305c0c33fe systemd[1833]: Started Virtual filesystem service.
Feb 24 04:20:30 5d305c0c33fe gvfsd[1883]: fuse: device not found, try 'modprobe fuse' first
Feb 24 04:20:30 5d305c0c33fe dbus-daemon[1868]: [session uid=1000 pid=1868] Activating via systemd: service name='org.a11y.Bus' unit='at-spi-dbus-bus.service' requested by ':1.4' (uid=1000 pid=1983 comm="nm-applet ")
Feb 24 04:20:30 5d305c0c33fe systemd[1833]: at-spi-dbus-bus.service: Failed to get cgroup ID on cgroup /sys/fs/cgroup/unified/docker.slice/docker-5d305c0c33fe419ff76ec89278ca1b51e9ffc3245186ac068bce6055836565db.scope/user.slice/user-1000.slice/user@1000.service/app.slice/at-spi-dbus-bus.service, ignoring: Operation not permitted
Feb 24 04:20:30 5d305c0c33fe systemd[1833]: Starting Accessibility services bus...
Feb 24 04:20:30 5d305c0c33fe dbus-daemon[1868]: [session uid=1000 pid=1868] Successfully activated service 'org.a11y.Bus'
Feb 24 04:20:30 5d305c0c33fe systemd[1833]: Started Accessibility services bus.
Feb 24 04:20:30 5d305c0c33fe at-spi-bus-launcher[2071]: dbus-daemon[2071]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1000 pid=1983 comm="nm-applet ")
Feb 24 04:20:30 5d305c0c33fe at-spi-bus-launcher[2071]: dbus-daemon[2071]: Successfully activated service 'org.a11y.atspi.Registry'
Feb 24 04:20:30 5d305c0c33fe at-spi-bus-launcher[2083]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry

I also have many errors that you do not have in your output.

[DiXN]

On another note x11docker-journal.service fails to start and I found an issue with PulseAudio since 40eba6c.

40eba6c#diff-0cf1bc31311c54f65de516fc6729fcf2d6c9f2d3beee93a5c249e16657909e7bR7326 breaks my PulseAudio setup while it works with 40eba6c#diff-0cf1bc31311c54f65de516fc6729fcf2d6c9f2d3beee93a5c249e16657909e7bR7327.

Do I have to change anything regarding options? Usually I run my container with -p.

[mviereck]

On another note x11docker-journal.service fails to start and I found an issue with PulseAudio since 40eba6c.

Oops, sorry. There was some experimental code for --pulseaudio=tcp that should not have been uploaded (tests for #418 ). I've removed it. Btw., it seems that a tcp connection is used for your container although socket mode is default for most setups.

[mviereck]

I've build an arch image to reproduce your issues.
At first, automatic login fails here, too, so loginctl does not show the user but only a lingering state.
x11docker uses su to trigger a login with loginctl. This works with debian, but not with arch, as it seems.
If I run with --sudouser, switch to root and run login, I get a user session in loginctl. Unfortunately login needs interaction, so I cannot use it for an automatic login script.

[mviereck]

If I change this line: https://github.com/mviereck/x11docker/blob/master/x11docker#L6293

[ -e /sbin/agetty ] && exec agetty -a \$Containeruser -l /usr/local/bin/x11docker-login console

to

[ -e /sbin/agetty ] && exec agetty -a \$Containeruser console

and run x11docker with --interactive, I get an automated login and a valid loginctl output.

But I have to find another way to run /usr/local/bin/x11docker-login or sh /x11docker/containerrc as user. I am currently not sure how to achieve this.

Edit: meanwhile I can run a user session, looks good so far. arch shows a valid loginctl output.
Yet I try to check and fix some different setup combination, notable with --interactive.

[mviereck]

I've uploaded a commit that works well for me with --init=systemd and an arch image.
Instead of su it uses login to trigger logind.

The final container command is not started by a service as before (neither system nor user service) but by running the command in /etc/profile.d. This is sort of a hack, but i think it is ok. It mimics the behaviour of a display manager that runs a custom login command.

loginctl enable-linger USER is not used anymore, but was a useful step in developing and understanding the overall setup.

I could not reproduce your journald issue. Could you elaborate what is going wrong?

Now I'll check the other supported init systems if x11docker could run them with a login setup, too.

[DiXN]

I have a valid login session now as well.

However oddly enough I now have an issue with tmux crashing my image. Every time I launch Alacritty with tmux it instantly kills my container and prints awesome: acquire_WM_Sn:311: another window manager is already running (selection owned; use --replace). Changing to my user in a SSH session shows the following error error connecting to /tmp/tmux-1000/default (No such file or directory).
To be fair it also crashes Alacritty on my main system when launched after shell startup explicitly with the message sessions should be nested with care, unset $TMUX to force but I guess it should not kill the whole container. Another difference compared to my main system is that the environment variable $TMUX is not set .

Maybe the watch service end gets triggered for some reason in this scenario?

I could not reproduce your journald issue. Could you elaborate what is going wrong?

The only log that i have for this issue is Using --boot or --list-boots with --merge is not supported. in /x11docker/systemd.journal.log.

[mviereck]

Could you show me your x11docker command?

And maybe also provide your Dockerfile so I could directly reproduce your issues?

awesome: acquire_WM_Sn:311: another window manager is already running (selection owned; use --replace)

Maybe x11docker started a WM. Use option --desktop to avoid this.

The only log that i have for this issue is Using --boot or --list-boots with --merge is not supported. in /x11docker/systemd.journal.log.

x11docker used journalctl with option --merge. I am not sure yet why I've added that at all. However, I've removed that option, maybe that fixes it. Now I get even some more boot messages, that's nice.

Maybe the watch service end gets triggered for some reason in this scenario?

Hmm. It would be triggered if the final desired command would exit. If your targeted command Alacritty crashes, that would also terminate the container. Or if the container login console itself crashes, e.g. because tmux messes it up.

[DiXN]

Could you show me your x11docker command?

This has been my command throughout all my tests.

x11docker --clipboard --init=systemd --shell=/bin/zsh -I -p --desktop --user=RETAIN --cap-default --sudouser --gpu --xorg arch-nv-full

Maybe x11docker started a WM. Use option --desktop to avoid this.

This indeed makes it work in the first place otherwise the container won't even start, however I have been doing this since the beginning. I think that something might have changed concerning the D-Bus connection or because of the way signing in now works, the tmux server cannot create /tmp/tmux-1000/default.

If you want to test this yourself you have to be aware that my container image is about 8GB large as it is more or less my whole system.

https://raw.githubusercontent.com/DiXN/dotfiles/chezmoi/linux/Dockerfile

[mviereck]

If you want to test this yourself you have to be aware that my container image is about 8GB large as it is more or less my whole system.

Uh, ok. That is a bit heavy.
I'll try to build a smaller image with only the parts that fail in your setup.
My current Dockerfile:

FROM archlinux

RUN pacman -Sy --noconfirm systemd-sysvcompat bash xterm
RUN pacman -S --noconfirm archlinux-keyring
RUN pacman -Sy --noconfirm shadow pambase
RUN pacman -Sy --noconfirm tmux awesome zsh alacritty
CMD xterm

But the build fails at the last RUN line:

[...downloading packages...]
checking keyring...
checking package integrity...
error: lua53-lgi: signature from "Caleb Maclennan <alerque@archlinux.org>" is marginal trust
:: File /var/cache/pacman/pkg/lua53-lgi-0.9.2-7-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] error: awesome: signature from "Caleb Maclennan <alerque@archlinux.org>" is marginal trust

:: File /var/cache/pacman/pkg/awesome-4.3-3-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package)

Errors occurred, no packages were upgraded.

I am barely familiar with arch, do you have a hint how to fix this?

[DiXN]

I am barely familiar with arch, do you have a hint how to fix this?

Could be a key issue. You might have to run sudo pacman-key --init first. I however did not have to do anything and your Dockerfile did build without a problem on my machine.

I also setup a minimal Dockerfile where my config is present and all the dependencies that are required for Alacritty. This setup is significantly smaller than my actual docker image.

https://raw.githubusercontent.com/DiXN/dotfiles/minimal/linux/Dockerfile

[mviereck]

I think that something might have changed concerning the D-Bus connection or because of the way signing in now works

You are right, I changed the Dbus setup and got issues here, too. Normally the Dbus user session should start on itself as soon as it is needed, but this seems to fail.
Now x11docker (again) starts a new Dbus session manually with dbus-run-session. I might change this again starting dbus user services manually. But for now the issue is fixed.

I also setup a minimal Dockerfile where my config is present and all the dependencies that are required for Alacritty. This setup is significantly smaller than my actual docker image.

Thank you, that is very useful! I had to add awesome manually, it is missing.

In my test runs tmux, awesome and alacritty work well now.

I now can reproduce your error messages during boot, all concerning failed cgroup setups, e.g. at the beginning:

-.slice: Failed to get cgroup ID on cgroup /sys/fs/cgroup, ignoring: Operation not permitted
system.slice: Failed to get cgroup ID on cgroup /sys/fs/cgroup/system.slice, ignoring: Operation not permitted
system-modprobe.slice: Failed to get cgroup ID on cgroup /sys/fs/cgroup/system.slice/system-modprobe.slice, ignoring: Operation not permitted

Interesting comparision: I have an arch image that is 11 month old. Images build upon this do not have these cgroup errors. (But pacman key issues for some packages.)

The cgroup errors seem to do no harm, everything works here as expected. But I'll investigate further if they can be fixed.

Edit:
arch systemd version showing cgroup errors: systemd 250.3-4
arch systemd version without cgroup errors: systemd 247.3-1
Yet built an image with debian testing and systemd 250.3-2: Also shows cgroup errors.

I had a look at systemd news in https://github.com/systemd/systemd/blob/main/NEWS searching for keyword 'cgroup', but found nothing that explains the issues.

This ticket might be related and indicates that the messages are harmless: systemd/systemd#22483

Interesting: I don't get cgroup errors if I use --backend=podman.
x11docker tries to mimic podman setup for systemd, but it seems something is still different. #349

Running with sysbox-runc did not fix the messages although Sysbox grants all capabilities to containers.

[DiXN]

Overall I did not come across any issues while testing. polkit seems to correctly ask for a password when systemctl is used without sudo. Does x11docker set a password for root other than x11docker?

Thank you, that is very useful! I had to add awesome manually, it is missing.

That was a deliberate decision since I did not think that awesome had anything to do with the issue.

This ticket might be related and indicates that the messages are harmless: systemd/systemd#22483

That is interesting and could be the reason in my case since I am using an older kernel (5.13).

Interesting: I don't get cgroup errors if I use --backend=podman.

I actually would rather use podman instead of docker but could not get it to work with nvidia. I have to test this again in the future.

[mviereck]

Does x11docker set a password for root other than x11docker?

It always sets the same password for the user as well as for root. You can set and store another password with option --password. Would you need it to be different for user and root?

That was a deliberate decision since I did not think that awesome had anything to do with the issue.

It was set as ENTRYPOINT. :-)

That is interesting and could be the reason in my case since I am using an older kernel (5.13).

If the reason is the kernel version than you should get the same messages on host.

I actually would rather use podman instead of docker but could not get it to work with nvidia. I have to test this again in the future.

Did you test with x11docker? I have no nvidia card, so I cannot test myself.

[DiXN]

After terminating a container I still have a user session on my host device. Maybe x11docker should terminate the session on container end.

It always sets the same password for the user as well as for root. You can set and store another password with option --password. Would you need it to be different for user and root?

For me it was not the same, that is why I am curious. It works once i change the password with passwd for root.

It was set as ENTRYPOINT. :-)

Oh that is my bad. I forgot to commit some changes to the Dockerfile.

Did you test with x11docker? I have no nvidia card, so I cannot test myself.

At the moment I can't but I will once I have access to a nvidia card again.

[mviereck]

After terminating a container I still have a user session on my host device. Maybe x11docker should terminate the session on container end.

I can not reproduce this. loginctl on host does not show me the container user.
Are you sure you see a login from a container on host?

For me it was not the same, that is why I am curious. It works once i change the password with passwd for root.

Does this happen with --user=RETAIN? In that case x11docker does not set a password because it does not configure the container user at all.
You could set the password in the Dockerfile, either with the passwd command or with COPY to add a custom /etc/shadow and /etc/passwd.

[mviereck]

I'd like to close the ticket.
Much thanks, you were a great help to find and fix several issues!

The remaining issues might be answered with my previous comment.
If the last issues are not solved or others occur, please tell me in a new ticket.