Remote Desktop Access to Real desktop on Linux using x11vnc (tested on Ubuntu and MX Linux)

Remote Desktop Access over VNC to real screen of MX Linux 

Remote Desktop Access over VNC to real screen of Ubuntu MATE

I have installed numerous VNC servers on Linux desktops over the years to access their graphical desktops remotely. This typically involved installing and launching an X server separate from the one serving the local desktop screen, along with a corresponding window manager and session manager different from the ones serving the local GUI desktop. This resulted in a different desktop being presented to VNC clients accessing the remote server. This desktop was independent of the actual ("real") desktop running on the remote machine's screen, which specifically made it impossible to access any open applications on the "real" desktop remotely.

The solution is to install x11vnc which presents the "real" desktop to VNC clients. I found and installed x11vnc from standard repositories on Ubuntu MATE and MX Linux. x11vnc works great on both distributions.

Here are my notes on how to do this.

Download and install x11vnc (and screen utility that we will use to run x11vnc) the usual way from repos:

# apt-get update
# apt-get install x11vnc screen

After downloading and installing x11vnc, as root create a VNC authentication password by entering the command:

# x11vnc -storepasswd
Enter VNC password: 
Verify password:    
Write password to /root/.vnc/passwd?  [y]/n y

Password written to: /root/.vnc/passwd

Then add the following to root's crontab (by running crontab -e):

#x11vnc - allow VNC connections to real X11 display
@reboot screen -S X11VNC-SERVER -m -d nice -n 19 ionice -c 3 x11vnc -usepw -nevershared -forever -no6 -display :0 -auth guess -loop

To start x11vnc right now instead of having to wait for the next reboot, type in:

screen -S X11VNC-SERVER -m -d nice -n 19 ionice -c 3 x11vnc -usepw -nevershared -forever -no6 -display :0 -auth guess -loop


Note: for enhanced security, you can limit x11vnc to listen to a specific interface by specifying the IP address of the interface to listen to using the additional switch "-listen ipaddr". From the man page:

-listen ipaddr         listen for connections only on network interface with addr ipaddr. '-listen localhost' and hostname work too.


Check if the screen session is indeed up. For example,

# screen -ls
There are screens on:
16484.X11VNC-SERVER (03/06/2020 06:53:47 AM) (Detached)

Also check the actual screen contents. Continuing our example:

# screen -r 16484
06/03/2020 06:53:49 rfbListenOnTCP6Port: error in bind IPv6 socket: Address family not supported by protocol

06/03/2020 06:53:49 rfbListenOnTCP6Port: error in bind IPv6 socket: Address family not supported by protocol

06/03/2020 06:53:49 Failure autoprobing: Address family not supported by protocol

06/03/2020 06:53:49

06/03/2020 06:53:49 Xinerama is present and active (e.g. multi-head).

06/03/2020 06:53:49 Xinerama: number of sub-screens: 1

06/03/2020 06:53:49 Xinerama: no blackouts needed (only one sub-screen)

06/03/2020 06:53:49

06/03/2020 06:53:49 fb read rate: 1371 MB/sec

06/03/2020 06:53:49 fast read: reset -wait  ms to: 10

06/03/2020 06:53:49 fast read: reset -defer ms to: 10

06/03/2020 06:53:49 The X server says there are 10 mouse buttons.

06/03/2020 06:53:49 screen setup finished.

06/03/2020 06:53:49

The VNC desktop is:      dell-poweredge-r710:0

PORT=5900

******************************************************************************

Have you tried the x11vnc '-ncache' VNC client-side pixel caching feature yet?

The scheme stores pixel data offscreen on the VNC viewer side for faster

retrieval.  It should work with any VNC viewer.  Try it by running:

    x11vnc -ncache 10 ...

One can also add -ncache_cr for smooth 'copyrect' window motion.

More info: http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching

Press Control-a and then d to detach from the screen session (x11vnc keeps running inside the detached screen).

The "PORT=900" on the screen above confirms VNC server is listening on port 5900. We can, therefore, run a VNC client on a remote computer and point it to x11vnc server's and port 5900 to access the desktop over network. For example, from a remote client (I installed the tigervnc-viewer package on a remote MX Linux laptop to get vncviewer ):

$ vncviewer dell-poweredge-r710:5900

You will be asked to enter the VNC authentication password and then the remote X Windows desktop will be displayed on your screen.

TigerVNC viewer on MX Linux laptop displays remote Ubuntu desktop running SANYALnet Labs virtual boxes

Color Bars, Grey Screen or White Screen on 2011 MacBook Pro - Bypass / Disable the AMD Radeon GPU

Color Bars due to faulty AMD Radeon GPU on Late 2011 MacBook Pro 1297 17"

Along with numerous disappointed Apple enthusiasts, I was hit with the Radeongate scandal on my trusty old late-2011 17" MacBook Pro 8,3 model A1297 (MD311LL/A). Bars of various colors, white screen or grey screen on boot, etc. - I saw them all and was about to give up on the computer.

I use my Mac just for email, web browsing and iTerm2 to login and have fun with my zoo of virtual machines which I call SANYALnet Labs. There is no real need here for accelerated 3D graphics delivered by the AMD Radeon HD 6770M discrete (second) graphics processor unit that Apple included in 2011 models connected internally to the PCIe bus. The built-in Intel HD Graphics 3000 graphics processor is good enough.

So when I was told I could tweak my MacBook Pro such that MacOS X High Sierra would use the Intel GPU exclusively instead of the Radeon, I jumped on the opportunity. As a result, I am now happily typing this post on the fully-functional-without-AMD-Radeon MacBook Pro.

How did I do it? Just followed the instructions in the awesome reply by LаngLаngС in this post at stackexchange. In fact, that post is so important to me that I saved a PDF copy in my google drive just in case it becomes inaccessible online.

I only performed the steps starting from "The initial procedure" section through and including "Preventive measures for future use". I then disabled auto-updates from System Preferences -> App Store. High Sierra was released in September of 2017 and superseded by Mojave in September of 2018. I can live with no more automatic updates for High Sierra which is the last operating system supported by my MacBook Pro anyway.

I had to deviate a little in some of the steps for my specific model, though. The command line "csrutil disable" to disable SIP did not work in single-user recovery mode (hold down Command + R + S); it actually complained it has to be run from "recovery operating system". I subsequently booted into Recovery mode (hold down Command + R at the chime) and typed the command line into a terminal in recovery mode. It worked. Another deviation from the guide was that I could execute the command to set "agc" in NVRAM from a terminal from the full MacOS X High Sierra desktop. This must be because I disabled SIP as one of the steps in the initial procedure.  I first did a

# sudo su -

to become root and then executed

# nvram boot-args="-v agc=0"

and restarted.

Following the advice in the "Preventive Measures for Future Use" section, I have saved the all-important command to update the NVRAM in a shell script at /force-intel-gpu-boot.sh. Whenever a SMC or NVRAM reset overwrites the configuration to force the Intel GPU, all I have to do to get back enough control:

1. Boot into single-user (Command + S at chime)
2. Mount the boot volume read-write:
   # /sbin/mount -uw /
3. Execute the shell script:
   # sh /force-intel-gpu-boot.sh

I can then reboot, and log back in and open a terminal from which I can reconfigure the NVRAM variable directly since SIP has been disabled:

# nvram boot-args="-v agc=0"

If SIP happens to be still enabled, the command above needs to be run from single-user recovery mode which is entered by holding down Command + R + S at the chime.