If the environment variable $XAUTHORITY is somehow lost then Xvnc will reject the X11 connection and applications will fail to function. This is a fairly rare condition, but happens sometimes with complex setups. And it does work locally so it should work in ThinLinc. The reason it works locally is because modern distributions configure their X server to allow all connections from the same user: > $ xhost > access control enabled, only authorized clients can connect > SI:localuser:ossman Not so in ThinLinc: > $ xhost > access control enabled, only authorized clients can connect And you can easily test the difference between local: > $ XAUTHORITY= xdpyinfo > name of display: :0 > version number: 11.0 > vendor string: Fedora Project > ... and in ThinLinc: > $ XAUTHORITY= xdpyinfo > No protocol specified > xdpyinfo: unable to open display ":10".
I think I stumbled upon the same problem but not in a very complex setup. tl-4.13.0 server Ubuntu 20.04 gnome-session and gdm3 installed Chromium 94.0.4606.81 snap Trying to run chromium inside ThinLinc session I get: > $ chromium > No protocol specified > [6761:6761:1020/112608.034506:ERROR:browser_main_loop.cc(1400)] Unable to open X display. Running chromium locally works fine. And when I disable access control it also works fine inside the ThinLinc session: > $ xhost + > access control disabled, clients can connect from any host > $ chromium
https://gitlab.freedesktop.org/xorg/xserver/-/commit/4b4b9086d02b80549981d205fb1f495edc373538
This got fixed in bug 7788.
