VNC Broken in 11.1 KDE and GNOME

English Applications
41

This is an ancient thread, but I ran into something with openSUSE-11.1 and x11vnc earlier today (over 1 year later) that has me a bit puzzled.

Typically, my method to open a remote VNC session from Linux PC to Linux PC is to open two terminals on the PC where I am sitting, and type:

ssh -t -L 5900:localhost:5900 remote-username@remote-pc-ip-address 'x11vnc -localhost -nolookup -nopw -display :0'

where ‘remote-username’ is the username on the remote PC, and ‘remote-pc-ip-address’ is the IP address of the remote PC.

Then I type in the 2nd terminal in front of me, and it reads the vnc output that is being streamed to my desktop via the ssh pipe:

vncviewer -encodings "tight copyrect hextile" localhost:0

and the connection ‘just works’. At least it has worked for me in openSUSE-10.1, 10.2, 10.3, 11.0, 11.1, 11.2, and 11.3 with KDE. I recall vaguely during the development of openSUSE-11.1 there was a hiccup with KDE (some sort of permissions issue ?? ) but it was solved before the final openSUSE release (I think, … or was there a work around I applied that I can’t recall ?? ).

Anyway, I installed the old openSUSE-11.1 on my wife’s old Fujitsu-Siemens Amilo 7400M laptop, and much to my surprise, **the above did not work ! **

**Surprisingly what DID work **was to type ‘x11vnc’ on the laptop (which is acting as the remote PC), and then on my desktop type:

vncviewer -encodings "tight copyrect hextile" remote-pc-ip-address:0

where ‘remote-pc-ip-address’ is the laptop’s IP address. Of course that is incredibly insecure as anyone can connect, but what is IMPORTANT here is that works.

Now if I open a terminal on my main PC, and ssh to the laptop, and I run x11vnc, and then try the above

vncviewer -encodings "tight copyrect hextile" remote-pc-ip-address:0

it does NOT work. ie x11vnc MUST be run by a local user and NOT by a remote user !

ie it makes me suspicious there has to be some sort of permissions problem with GNOME on openSUSE-11.1 that was solved with KDE but not with Gnome.

Or did I forget some work around I applied to KDE on 11.1 a long time back ?

42

I’m currently reading this: x11vnc: a VNC server for real X displays

Q-1: I can’t get x11vnc to start up. It says “XOpenDisplay failed (null)” or “Xlib: connection to “:0.0” refused by server Xlib: No protocol specified” and then exits. What do I need to do?

For the former error, you need to specify the X display to connect to (it also needs to be on the same machine the x11vnc process is to run on.) Set your DISPLAY environment variable (or use the -display](http://www.karlrunge.com/x11vnc/x11vnc_opts.html#opt-display) option) to specify it. Nearly always the correct value will be “:0” (in fact, x11vnc will now assume :0 if given no other information.)

For the latter error, you need to set up the X11 permissions correctly.

To make sure X11 permissions are the problem do this simple test: while sitting at the physical X display open a terminal window (gnome-terminal, xterm, etc.) You should be able to run x11vnc successfully without any need for special steps or command line options in that terminal (i.e. just type “x11vnc”.) If that works OK then you know X11 permissions are the only thing preventing it from working when you try to start **x11vnc ** via, say, a remote shell.

How to Solve: See the xauth(1), Xsecurity(7), and xhost(1) man pages or this Howto for much info on X11 permissions. For example, you may need to set your XAUTHORITY environment variable (or use the -auth](http://www.karlrunge.com/x11vnc/x11vnc_opts.html#opt-auth) option) to point to the correct MIT-MAGIC-COOKIE file (e.g. /home/joe/.Xauthority or /var/gdm/:0.Xauth or /var/lib/kdm/A:0-crWk72K or /tmp/.gdmzndVlR, etc, etc.), or simply be sure you run x11vnc as the correct user (i.e. the user who is logged into the X session you wish to view.)

Note: The MIT cookie file contains the secret key that allows x11vnc to connect to the desired X display.

If, say, sshd has set XAUTHORITY to point to a random file it has created for X forwarding that will cause problems. (Under some circumstances even su(1) and telnet(1) can set XAUTHORITY. See also the gdm parameter NeverPlaceCookiesOnNFS that sets XAUTHORITY to a random filename in /tmp for the whole X session.)

Running x11vnc as root is often not enough: you need to know where the MIT-MAGIC-COOKIE file for the desired X display is.

Example solution:

x11vnc -display :0 -auth /var/gdm/:0.Xauth

(this is for the display manager gdm and requires root permission to read the gdm cookie file, see this faq for other display manager cookie file names.)

Note as of Feb/2007 you can also try the -find](http://www.karlrunge.com/x11vnc/x11vnc_opts.html#opt-find) option instead of “-display …” and see if that finds your display and Xauthority.

Less safe, but to avoid figuring out where the correct XAUTHORITY file is, if the person sitting at the physical X session types “xhost +localhost” then one should be able to attach x11vnc to the session (from the same machine.) The person could then type “xhost -localhost” after x11vnc has connected to go back to the default permissions. Also, for some situations the “-users lurk=” option may soon be of use (please read the documentation on the -users](http://www.karlrunge.com/x11vnc/x11vnc_opts.html#opt-users) option.)

To test out your X11 permissions from a remote shell, set DISPLAY and possibly XAUTHORITY (see your shell’s man page, bash(1), tcsh(1), on how to set environment variables) and type xdpyinfo in the same place you will be typing (or otherwise running) x11vnc. If information is printed out about the X display (screen sizes, supported extensions, color visuals info) that means the X11 permissions are set up properly: xdpyinfo successfully connected to DISPLAY! You could also type xclock and make sure no errors are reported (a clock should appear on the X display, press Ctrl-C to stop it.) If these work, then typing “x11vnc” in the same environment should also work.

Important: if you cannot get your X11 permissions so that the xdpyinfo or xclock tests work, x11vnc also will not work (all of these X clients must be allowed to connect to the X server to function properly.)

Firewalls: Speaking of permissions, it should go without saying that the host-level firewall will need to be configured to allow connections in on a port. E.g. 5900 (default VNC port) or 22 (default SSH port for tunnelling VNC.) Most systems these days have firewalls turned on by default, so you will actively have to do something to poke a hole in the firewall at the desired port number. See your system administration tool for Firewall settings (Yast, Firestarter, etc.)
… maybe I’m just thick, but I find that read rather ‘heavy going’. :frowning: