HOWTO: Set up VNC server with resumable sessions

[PhDLinux]

Thanks to Crass Spektakel for Post #605 above! I got this working on Lucid Lynx, Ubuntu Studio edition, with some minor changes.

Here is an exact copy of one stanza in my file /etc/xinetd.d/Xvnc. This one serves the netbook:

service vnc1024x600
{
  type           = UNLISTED
  disable        = no
  port           = 5911
  socket_type    = stream
  protocol       = tcp
  wait           = no
  user           = nobody
  server         = /usr/bin/Xvnc4
  server_args    = -inetd -once -SecurityTypes None -geometry 1000x600 -depth 24 -fp /usr/share/fonts/X11/misc/ -co /usr/share/X11/rgb -query localhost
  log_type       = SYSLOG daemon info
  log_on_failure = HOST
  log_on_success = PID HOST EXIT
}

The added logging commands helped me figure out some changes suggested below.

I inserted one corresponding line in the lengthy file /etc/services, as follows:

vnc1024x600     5911/tcp			# VNC 1024x600  @ 24bpp

(Perhaps the "UNLISTED" directive in the Xvnc file makes this redundant, but I want to thoroughly document everything. The port number 5911 shown here must match the port number declared in the Xvnc file shown above.)

Here is my key difference from the cited post (without this my connection attempts would flash a grey X screen for a fraction of a second and then quit). I had to add two extra lines to the end of the suggested gdm configuration file. Here is an exact copy of my complete file /etc/gdm/custom.conf:

[security]
DisallowTCP=false
[xdmcp]
Enable=true
MaxSessions=16
DisplaysPerHost=2

The cited post also mentions a file named /etc/X11/xserver/SecurityPolicy. My system does not even have a directory named /etc/X11/xserver, so I skipped the creation of this file. The setup works anyway.

Every time you change the file /etc/xinetd.d/Xvnc, it is necessary to restart the xinetd server *as root* ("sudo /etc/init.d/xinetd restart"). [When I forgot "sudo", the system supplied a user-mode xinetd server in addition to the system-wide one, and things got confusing.] Similarly, changes to /etc/gdm/custom.conf don't actually take effect until you restart the display manager ("sudo service gdm restart"). Note that restarting gdm terminates your session completely and sends you back to the login screen instantly.

As a preliminary step, I used the command line to practice giving the Xvnc command that the xinetd daemon would ultimately emit. I picked a port number different from the ones xinetd was busy listening to (my choice was 5903) and replaced the option "-inetd" with the string ":3" to get this command. No need to run as root:

$ Xvnc4 :3 -SecurityTypes None -geometry 1000x600 -depth 24 -fp /usr/share/fonts/X11/misc/ -co /usr/share/X11/rgb -query localhost

Seeing a small-sized greeter screen in response to "vncviewer localhost:3" meant it was safe to take the next step and get xinetd involved. Of course there were many failures before this point, and they came with helpful messages -- something you don't get when relying on xinetd!

[errodrigues]

Thanks a lot Crass Spektakel!!! Ihad already spent more than 1 day trying to make this thing work on my Lucid and your instructions did the trick.

I don't need 2 services running so I just created 1 and it works like a charm now. Only thing I added was including "gdm: localhost" to file /etc/hosts.allow

Thanks again!

[vyath]

I managed to set things up like Spektakel and it works great, only now if I remotely login and try to access a connected USB drive (from "places", for example) I get
"Unable to mount X filesystem, Not authorized"

How do I fix it?

[KillerPancake]

After trying a lot of different things, I was FINALLY able to get a VNC server up and working reliably (sort of!) on 10.04. It was the sage advice of Crass Spektakel and PHDLinux that did the trick.

My goal is to setup a headless server that can live in the basement, toiling in obscurity while not taking up any space or generating heat in prime living space. Having gotten everything set up and working well, I dragged the box downstairs and started it up. Fired up the VNC viewer on my laptop and only got the X11 screen when connecting to the server, so I dragged the box back upstairs to investigate. Started up the box again, and this time no problems with the VNC viewer on the laptop. So, back downstairs with the machine, and again only got the X11 screen in the VNC viewer. What, is the machine lonely in the basement and protesting!? Other than this issue, the machine seems fine and I can access shares without problems, no matter where the server is.

So one of two things is happening:
1) Something is happening due to the difference in location - main difference in the basement is that keyboard, monitor and mouse are not connected and a different Ethernet cable connects the server to a switch
2) Some problem is occurring intermittently and its just coincidence that it shows up when the computer is moved to the basement

I would appreciate anyone's insight as to what might be happening here! Below are the outputs of the VNC viewer during a good connection, followed by a failed connection with X11 screen only.

Successful connection:
Tue Jul 13 23:29:34 2010
CConn: connected to host 192.168.1.105 port 5920
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
TXImage: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding

Tue Jul 13 23:29:37 2010
CConn: Throughput 4000 kbit/s - changing to hextile encoding
CConn: Throughput 4000 kbit/s - changing to full colour
CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
CConn: Using hextile encoding

Failed connection (note the last 5 lines are missing compared to above):
Wed Jul 14 00:02:25 2010
CConn: connected to host 192.168.1.105 port 5920
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
TXImage: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding

[Crass Spektakel]

Actually with the newer versions you can configure a remote desktop from System>Personal>Remote Desktop.

This is different from the objective of this topic:

Your method allows for remote control of the local, physical screen (though i must say this has always been very edgy and unreliable within ubuntu for me).

This topic is about creating virtual sessions, eg. if someone connects to port 5920 he will get a seperate VNC session not connected to the local, physical screen. This also means that several people can log in over VNC and work seperately. This has proven to be rockstable even with 10 or more people logging in at once.

--- cut ---

Thanks to Crass Spektakel for Post #605 above!

I have to thank you too, your logging-statements are pretty helpful. About the following:

[security]
DisallowTCP=false
[xdmcp]
Enable=true
MaxSessions=16
DisplaysPerHost=2

I am pretty sure that the last two lines are NOT required - they are useful sometimes though. Try putting one or two blank lines there instead and it will work too.

Reason: Many unix tools have a problem reading config files which don't end in a newline so basically the last line "Enable=true" gets ignored. I think this has been haunting us since before mankind visited the moon

[scaltro]

This tutorial seems to be very helpful thanks to all...

But unfortunately I have some problems....
When I'm trying to connect to my vnc server, I got a grey window in which I'm able to move the cursor, but nothing else... Any idea?

My /etc/gdm/custom.conf is as default:

[daemon]

[security]
DisallowTCP=false

[xdmcp]
Enable=true

I'm working on a fresh install of Ubuntu 10.04.

[Crass Spektakel]

Now I have run into something odd myself...

I have four nearly identically configured systems. One of them decided to display the grey screen upon vnc connect from time to time.

Restarting xinetd and gdm doesn't do the trick but rebooting does. I really have no idea where this comes from as all log file are clean and nice. It only happens rarely so I haven't investigated much. I think I did some inner works on the system though, lots of updates, configuring, changing runlevels, all that will produce the effect pretty reliable. But sometimes, once a month or less, it happens without good reason at all.

Keep in mind: If things dont work, reboot.

[howardjacobson]

As of September 17, 2010, the instructions most recently posted on pages 61 and 62 of this thread work for Lucid 10.04. Thank you to all for the great help!

[jmontani]

what should I write in the server parameter in a home network? I only
have the computers names available (i.e pc01; pc02, etc)

[popzero]

After trying a lot of different things, I was FINALLY able to get a VNC server up and working reliably (sort of!) on 10.04. It was the sage advice of Crass Spektakel and PHDLinux that did the trick.

My goal is to setup a headless server that can live in the basement, toiling in obscurity while not taking up any space or generating heat in prime living space. Having gotten everything set up and working well, I dragged the box downstairs and started it up. Fired up the VNC viewer on my laptop and only got the X11 screen when connecting to the server, so I dragged the box back upstairs to investigate. Started up the box again, and this time no problems with the VNC viewer on the laptop. So, back downstairs with the machine, and again only got the X11 screen in the VNC viewer. What, is the machine lonely in the basement and protesting!? Other than this issue, the machine seems fine and I can access shares without problems, no matter where the server is.

So one of two things is happening:
1) Something is happening due to the difference in location - main difference in the basement is that keyboard, monitor and mouse are not connected and a different Ethernet cable connects the server to a switch
2) Some problem is occurring intermittently and its just coincidence that it shows up when the computer is moved to the basement

I would appreciate anyone's insight as to what might be happening here! Below are the outputs of the VNC viewer during a good connection, followed by a failed connection with X11 screen only.

Successful connection:
Tue Jul 13 23:29:34 2010
CConn: connected to host 192.168.1.105 port 5920
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
TXImage: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding

Tue Jul 13 23:29:37 2010
CConn: Throughput 4000 kbit/s - changing to hextile encoding
CConn: Throughput 4000 kbit/s - changing to full colour
CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
CConn: Using hextile encoding

Failed connection (note the last 5 lines are missing compared to above):
Wed Jul 14 00:02:25 2010
CConn: connected to host 192.168.1.105 port 5920
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
TXImage: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding

I think I hit the same issue as you did with this one, mine was after doing an upgrade from 8.04 LTS to 10.04 LTS for my headless/mouseless/keyboardless server.

Took me a while to figure this one out; finally found it by forcing my system to disable kernel mode setting. There's a description of what is needed to disable it here: https://wiki.ubuntu.com/X/KernelModeSetting
I used the change listed for radeon cards and then it forced my X system to use the vesa setup. (Note: in my /etc/modprobe.d/ directory it didn't have any of the file names listed under "Turning it off"; the purpose of the link is to create the files using the echo command...the webpage didn't really make that clear so I like to be extra explicit ). This little gem of an issue drove me crazy for a day wondering WTH was going on with that dam grey X display mouse doing remote vnc access.

Oh one other thing I've found that might be helpful is putting "DisplaysPerHost=2" in my /etc/gdm/custom.conf file under the [xdmcp] section so it looks like this:
[security]
DisallowTCP=false
[xdmcp]
Enable=true
HonorIndirect=false
DisplaysPerHost=2

If I don't have this in my config each time I logout using the UI it won't let me log back in (gives that stupid timeout "111" error in the terminal). That might be why PhDLinux added that into the custom.conf file.

Hope this helps some of my fellow Ubuntu users