When trying to connect from a Win10 client to a Ubuntu 18.04 server using TigerVNCViewer, I get an error indicating the connection was refused. This had been previously working, but apparently stopped working after a software update on the Ubuntu server.

There should not be any firewall active and vncserver and vncpasswd have been executed on the server. The output from several diagnostic commands is included below.

Any help in resolving this issue is greatly appreciated.

Commands on Win10 client:


unable to connect to socket: Connection refused (10061)

Commands on WSL on Win10 client:

  • Note that default telnet and ssh connections successful to from WSL and Cygwin on Win10 client
$ telnet 5901

telnet: Unable to connect to remote host: Connection refused

Commands on Ubuntu server:

$ uname --all

Linux FooHost 5.3.0-28-generic #30~18.04.1-Ubuntu SMP Fri Jan 17 06:14:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ ifconfig

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 fe80::eb13:faea:f55c:e235  prefixlen 64  scopeid 0x20<link>
        ether 10:bf:48:87:25:f6  txqueuelen 1000  (Ethernet)
        RX packets 11209  bytes 10099146 (10.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6759  bytes 2418488 (2.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet  netmask
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 6678  bytes 382526 (382.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6678  bytes 382526 (382.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$ vncserver --list

TigerVNC server sessions:

:1              3927

$ sudo iptables --list

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

$ sudo ufw status

Status: inactive

$ sudo lsof -P -i

systemd-r  491 systemd-resolve   12u  IPv4   1971      0t0  UDP localhost:53
systemd-r  491 systemd-resolve   13u  IPv4   1972      0t0  TCP localhost:53 (LISTEN)
avahi-dae  847           avahi   12u  IPv4  24646      0t0  UDP *:5353
avahi-dae  847           avahi   13u  IPv6  24647      0t0  UDP *:5353
avahi-dae  847           avahi   14u  IPv4  24648      0t0  UDP *:34033
avahi-dae  847           avahi   15u  IPv6  24649      0t0  UDP *:44878
sshd      1079            root    3u  IPv4  30370      0t0  TCP *:22 (LISTEN)
sshd      1079            root    4u  IPv6  30372      0t0  TCP *:22 (LISTEN)
dhclient  1169            root    6u  IPv4  28935      0t0  UDP *:68
cupsd     2762            root    6u  IPv6  26605      0t0  TCP ip6-localhost:631 (LISTEN)
cupsd     2762            root    7u  IPv4  26606      0t0  TCP localhost:631 (LISTEN)
cups-brow 2763            root    7u  IPv4  33998      0t0  UDP *:631
sshd      2848            root    3u  IPv4  33644      0t0  TCP Cheaptos:22-> (ESTABLISHED)
sshd      2954           rbohl    3u  IPv4  33644      0t0  TCP Cheaptos:22-> (ESTABLISHED)
Xtigervnc 3927           rbohl    7u  IPv4  34521      0t0  TCP localhost:5901 (LISTEN)
Xtigervnc 3927           rbohl    8u  IPv6  34522      0t0  TCP ip6-localhost:5901 (LISTEN)
inetd     4397            root    7u  IPv4  39902      0t0  TCP *:23 (LISTEN)
  • It looks like Xtigervnc may be listening only on the loopback ("localhost") interface - that's a good thing from a security POV however it means you will need to set up an SSH tunnel in order to connect to it from another host – steeldriver Feb 9 '20 at 1:12
  • Thanks! - Using tunneling with Putty, I was able to make a connection. I also found that the likely reason for tigervncserver listening only on localhost:5901 was the mis documented default on the -localhost [yes|no] option to vncserver – ManNamedJed Feb 9 '20 at 19:07

You will need to install dbus-x11, then restart both Win-KeX and vnc-server.

  1. Shut down VNC Server and Kex:
vncserver --kill :*
kex kill
kex stop
  1. Install dbus-x11:
sudo apt update
sudo apt install dbus-x11
  1. Restart Win-Kex:
kex -s

This YouTube video has more information that might be useful.


Try starting vncserver with the parameter -localhost no, this works for me.

vncserver -localhost no

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.