I came across this page: TightVNC (VNC Xvnc) on openSUSE as Client or Server (Remote Desktop Connections) since this is what I am trying to do. My environment: openSuse 11.3, no firewall, router is port forwarding correctly, and using vncviewer on Windows XP. Tightvnc works just fine when starting manually and I can connect from anywhere. It’s the starting as a service that doesn’t seem to work. I have followed the page and it reports “Failed to connect to server x.x.x.x:2” when attempting vncviewer. The script is at /home/axiomcrs/bin/vncservice.sh and it is executable. The crontab entry @reboot /home/your_name/bin/vncservice.sh has been to the axiom user and to root, but it does not seem to matter. Any suggestions?
16 sept and no answers. Must have slipped through the cracks somehow.
The crontab entry should be
@reboot /home/axiomcrs/bin/vncservice.sh
Yes, the crontab was setup like that. I’m thinking the issue may be that the script does not run the dbus-launch vncserver command as root. Because when I did it as user I got some sort of error message. When I did it as root, it ran without issue.
You should not run vncserver as root, just FYI. It becomes too easy to damamge your system.
Q1: Please post the exact contents of the script here.
Q2: You said “when I did it as user I got some sort of error message”. I’m confused. Did you mean that when you run the command “dbus-launch vncserver” by hand as user axiomcrs, you get an error message or did you mean when you run the script vncservice.sh as user axiomcrs, you get an error message?
Q3: what’s the error message?
Q4: please post the return you get when you run this command
crontab -l
Q5: please post the return you get when you run this command
ls -l /home/axiomcrs/.vnc
When I’m user axiom and I execute “dbus-launch vncserver” from the cli by hand, I get:
vncserver: Wrong type or access mode of /home/axiom/.vnc.
The script in dir /home/axiom/bin is:
#!/bin/sh
rm /tmp/.X11-unix/X*
dbus-launch vncserver :2
And it is executable.
I do not execute the script from the cli by thru the crontab.
Something I noticed from all the reading I’ve done about this is they always refer to the .vnc subdir of the home dir. I installed tightvnc thru sw management of Yast, but it did not create a .vnc subdir. Why not?
The output of “crontab -l” is:
DO NOT EDIT THIS FILE - edit the master and reinstall.
(/tmp/crontab.XXXXwVEw44 installed on Wed Sep 22 08:41:36 2010)
(Cron version V5.0 – $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
@reboot /home/axiom/bin/vncservice.sh
The output of ls -l /home/axiomcrs/.vnc is nothing since it does not exist.
I just created the .vnc dir off of the axiom home dir. Am I supposed to create it? I copied the vncservice.sh script into ~/.vnc. When I run “dbus-launch vncserver” by hand I get the same message “vncserver: Wrong type or access mode of /home/axiom/.vnc.”.
The output of “ls -l /home/axiom/.vnc” is:
total 8
-rwxr-xr-x 1 root root 56 2010-09-22 21:41 vncservice.sh
-rwxr-xr-x 1 root root 27 2010-09-02 14:27 xstartup
The script xstartup contains:
#!/bin/sh
/usr/bin/gnome &
- Your problem is that vncservice.sh belongs to user ‘root’ and usergroup ‘root’.
Use chmod to change it to user ‘axiom’ and usergroup ‘users’. - if that does not work, try moving vncservice.sh outside of ~/.vnc
- ~/.vnc/passwd and ~/.vnc/xstartup is auto generated when you exec ‘vncserver’ for the first time. Note: type vncserver only. do not specify any parameters. If you do, vncserver will not create the specified xstartup script. I don’t know if this is a bug
- then modify your vncservice.sh to specify the display session number that you want to use vncserver to create.
Hope this fixes your problem.
…and of course.
Reboot the system.
The file vncservice.sh should be in the directory bin at /home/axiomcrs/bin. Copy it to there, or create a new one there.
The cron entry is good.
You should run this command to change the owner of the script to axiomcrs:
sudo chown axiomcrs:users /home/axiomcrs/bin/vncservice.sh
The contents of the script are good.
The error message is consistent with the directory “.vnc” being absent.
The absence of the directory “.vnc” points to a mis-installation of TightVNC, maybe, or to a failure to initialise TightVNC properly by setting the password structure properly, maybe. Let’s look. Can you post here the response to this command:
rpm -qa | grep vnc
PS
Probably the directory .vnc was somehow created by root and is now owned by root, from the looks of the contents. (BTW you shouldn’t log on as the root user except as a last resort, if that’s what you did, just an aside).
Change the owner of .vnc to axiomcrs with the command:
sudo chown -R axiomcrs:users /home/axiomcrs/.vnc
The command rpm -qa | grep vnc produces:
xorg-x11-Xvnc-7.5_1.8.0-10.3.1.i586
x11vnc-0.9.9-3.1.i586
libgtk-vnc-1_0-0-0.3.10-3.1.i586
tightvnc-1.3.9-110.1.i586
Both the dir ~/.vnc and the vncservice.sh script have been changed to owner axiom and group users.
It seems to be working so far. The wrong ownership of dirs and scripts seems to have been the issue. Thanks.
Good to hear, glad to help
BTW I deleted the extra post for clarity and edited out your list of home folders as a security issue
Yeah I didn’t notice that when I added a reply it went to a second page. Thanks for the deletes. The vnc connection seems to get hung at times. The mouse moves but the desktop icons are gone and so is the taskbar. There doesn’t seem to be anyway to escape from this unless I am physically near the box and I reset it. This last time I was playing a game and then when I quit, the desktop did not come back. Is it possible to recover from this? Perhaps a second console like a :3 and then resetting the :2 console from the :3???
I don’t know what you can do to prevent a lockup.
But you can start multiple instances of vncserver and connect to whichever one you like. You could have a script like this:
#!/bin/sh
rm /tmp/.X11-unix/X*
dbus-launch vncserver :2
dbus-launch vncserver :1
And connect to one or the other as you prefer.
Or alternatively when you log in remotelyto instance :2 you could open a console window and run another dbus-launch command and start a second instance.