Uhm on the root user I see the same file that is a symlink:
lrwxrwxrwx - - root root 13 lug 2020 .Xauthority -> /var/run/xauth/*
I have reflected a little bit over that strange entry, and do think, I now do understand its meaning. I am not sure, the construction is valid, because I have never seen a symlink with a wildcard, yet, i.e. pointing to several files.
As I reported previously, "root" gets/can get several .xauth... files simultaneously, although with the same content (MIT-COOKIE). Now, ".Xauthority -> /var/run/xauth/*" could try to make .Xauthority point to all files in /var/run/xauth. As written, I do not know, if this is a valid construct. Anyways, at least one file has to appear in /var/run/xauth. So you should first check, (from) where your(!) xauth-files are generated, when they do not appear under (/var)/run/xauth [the var is unnecessary after the last filesystem rework (some very bad moves, in my opinion)].
You can check, where "your" xauth-files appear with (e.g.) "ps -aef | fgrep X". It will show you the X "session" command and the path to the "xauth"s. Then you might recreate the .Xauthority symlink to that path, including the "*".
In my view this should give you a ticket to access the X-Display.
As written before, I see it vital, that the target file (not the symlink!) may be read by its user, only.
Edit: regarding the logs, you can have a view at /var/log/Xorg.log.n for the X11 setup, but I doubt, you find something useful for your case, there. Then you can have a look into the .xerrors file in the respective users home(s). Finally I would have a look at /var/log/syslog, but with systemd this may no longer exist, so someone else has to tell you, how to achieve this with "journalctl" [also a step back, to have a binary file as a logfile, in my opinion - how do you look it up from a "live" system?].
