NoMachine
NoMachine enables you to access a graphical desktop of a computer over the network.
Until version 3.x, NoMachine was known as NX and available under GPL. There are derivatives based on core NX libraries like FreeNX and X2Go. The major drawback of these is that they utilise a built-in X server of nxagent, which originates from the year 2005 and some current X applications cannot run due to unsupported features available only in newer versions of X libraries.
Unlike some other remote desktop solutions (e.g. TeamViewer), NoMachine does not require an intermediary server to establish the connection.
Since NoMachine version 4, the software is proprietary and currently two editions are available: Free and Enterprise. Clients exist for Linux, MS Windows, macOS, Android and iOS.
The free edition allows to connect to an existing X display (also known as display shadowing of a live session with a physical display) or, if no X display is available (e.g. on head-less machines), NoMachine tries to start its own X server with the default Desktop environment automatically. The major limitation of the free edition is that only a single remote desktop session may run on the server.
Installation
Install the nomachineAUR package.
It includes both server and client tar balls. Note that the setup actually takes place by a post-installation script and therefore the list of files shown by command pacman -Ql nomachine is not complete!
In particular, the majority of NoMachine files are kept within /usr/NX directory, but a few more are added:
/etc/NX /etc/pam.d/nx /usr/lib/systemd/system/nxserver.service /usr/local/share/applications/NoMachine*.desktop /usr/share/polkit-1/actions/org.freedesktop.pkexec.nomachine.policy
The files created by NoMachine Player are stored in:
$HOME/.nx $HOME/Documents/NoMachine
The post-install script also creates a new user nx.
If you have X2Go or FreeNX installed as well, do not get confused that some files use similar names (i.e. /usr/bin/nx).
The nxserver.service does not need to be enabled and started on computers which will be used only as the client, but it must run on the server.
Usage
On the target computer, start/enable nxserver.service via systemd, or via menu in your desktop: Internet > NoMachine > NoMachine Service, which does the same via a GUI and offers extra info and configuration.
On the client, start the "Player" (menu Internet > NoMachine > NoMachine. Or start it with
/usr/NX/bin/nxplayer
It will search the LAN for available NoMachine servers or, if disabled or in a different subnet/WAN, you can type in the target hostname or IP address manually. The login credentials are the same as used for the user on the target computer.
Troubleshooting
Headless server
Install the xorg-xauth package
For correct environment setup those changes are needed:
/etc/pam.d/nx
auth include system-remote-login account include system-remote-login password include system-remote-login session include system-remote-login
Change DefaultDesktopCommand in /usr/NX/etc/node.cfg and add the following in front of your starting command:
env DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus
Example for starting Xfce:
DefaultDesktopCommand "env DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus /usr/bin/startxfce4"
Separate NoMachine X session in parallel with existing X session
In default setup, the Free edition of NoMachine connects the client directly to an existing X session on the remote computer, even if it runs the X Display Manager only. This may be unwanted, because no other user may use the target computer locally at the same moment and because any person with physical access to the target computer can see on the physical display, what the remotely connected user is doing.
However, it is possible to setup NoMachine to check only for a particular DISPLAY, e.g. DISPLAY :10 and it will ignore the existing X session on (standard setup in Arch Linux) and start a new virtual session for the remotely connecting user.
To do so, edit the key in /usr/NX/etc/node.cfg:
PhysicalDisplays :10
Problems with default keyboard in display manager
When NoMachine connects to the display manager on the target computer and the user tries to login as if sitting at the target computer, the user authentication may fail due to a different keymap. A workaround is to type the user's password e.g. in a text editor and copy it via clipboard to the NoMachine session.
Once the user is logged in to the remote desktop environment, running ('cz' stands for the Czech keyboard as an example) should resolve the problem with key mappings.
Connecting via SSH
The free edition of NoMachine does not allow to use the SSH protocol to connect to the target computer and only NX protocol (listening on port by default) is used.
If it is not preferred to open yet another port on the firewall, a workaround is to create a standard SSH tunnel between client and target computer and connect through it:
On the client computer, for example:
$ ssh -L 4000:localhost:4000 user@targetmachine -fN
Then, start NoMachine Player and try to connect to localhost with the NX protocol. The connection will be tunneled to the targetmachine and redirected to the server's localhost port .
Virtualbox guest audio stream lost on reconnection
If using PulseAudio audio interface, nxserver will restart pulseaudio on client disconnection, virtualbox guest machine can not connect to the new pulseaudio automatically, thus audio stream lost. A workaround is to provide a dummy pulseaudio in your PATH for nxserver.
$ ln -s /usr/bin/true /some/path/prior/to/usr/bin/pulseaudio $ which -a pulseaudio /some/path/prior/to/usr/bin/pulseaudio /usr/bin/pulseaudio
Then reinstall the nomachineAUR package to regenerate /usr/NX/etc/node.cfg, and recheck the pulseaudio start command.
$ grep -i pulse /usr/NX/etc/node.cfg AudioInterface pulseaudio CommandStartPulseAudio "/some/path/prior/to/usr/bin/pulseaudio --high-priority=no"
Finally restart nxserver.service.