That is not true. The X0 socket is still there it just seems that it's isolated from the rest of the filesystem. You can check this via lsof and you will get for example this:

Xorg 673 674 chris 43u unix 0xffff97a489ffdc00 0t0 118253 @/tmp/.X11-unix/X0 type=STREAM

@shibumi

Unless I'm mistaken, the issue is that the filesystem entry in the host is unlinked by systemd-nspawn, preventing future connections to the socket on either the container or the host.

Existing connections to /tmp/.X11-unix/X0 are unaffected by deleting the fs entry, so naturally lsof will show that the file handle is still held by existing processes.

Lennart Poettering #6979 (comment):

Well. Thats a general problem of making host things available to the container in a writable way. Quite frankly the right way to fix this is to use --bind-ro= instead of --bind= so that the container payload cannot modify what you pass in. That should fix your issue robustly and safely.

Evidently, the readonly mount flag does not prevent connect() on the socket, so mounting with --bind-ro is OK.

@guns how does this solve anything? I tried that with my container.. now I get this message:
Spawning container on root directory is not supported. Consider using --ephemeral.

And with --ephemeral I get: --ephemeral and --link-journal= may not be combined.

And without --link-journal I get a:
Job for systemd-nspawn@work.service failed because a timeout was exceeded.
Are you sure that issue is fixed?

That is my full override.conf:

ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --settings=override --machine=%I --capability=CAP_NET_ADMIN --network-veth --bind=/tmp/.X11-unix:/tmp/.X11-unix --setenv="DISPLAY=:0"

@shibumi

Are you sure that issue is fixed?

I am sure that my original issue is fixed, because I can successfully launch X client programs from a container launched with --bind-ro=/tmp/.X11-unix.

I'm not sure why your container is failing to boot, however.

Sure. I create shell scripts that exec into systemd-nspawn invocations. Here is a minimal reproducible example:

#!/bin/sh

exec /usr/bin/systemd-nspawn \
    --machine=NAME \
    --boot \
    --setenv=DISPLAY="$DISPLAY" \
    --bind-ro=/tmp/.X11-unix

mh as I thought. Your setup is very simple and you don't register your machine to systemd-machined nor you set things like --network-veth. I can just say that the current systemd version breaks my container setup.

Should I open a new issue for this or do we re-open this one? I used the container to use a seperate VPN and spawn applications out of this container (like a web-browser). This way I could work with 2 browsers at the same time. One with VPN, the other one without.

Your setup is very simple and you don't register your machine to systemd-machined nor you set things like --network-veth

Like I said, it was a minimal example. I use --link-journal=try-guest --private-network --network-veth with my actual containers, and can control them externally with machinectl.

Should I open a new issue for this or do we re-open this one?

Since it can be demonstrated that --bind-ro=/tmp/.X11-unix does not prevent X clients launching from within the machine, your problem appears to be a separate issue.