ThinLinc: Linux Remote Desktops and VDI

Linux remote desktop infrastructure has a long history of half-measures: plain VNC with no session brokering, X2Go that struggles with modern desktop environments, xrdp bolted awkwardly onto a protocol designed for Windows, and NoMachine that works brilliantly until you read the license. ThinLinc, built by the Swedish company Cendio, occupies an unusual and underappreciated position in this space. It is a full virtual desktop infrastructure (VDI) platform built entirely on open-source foundations — TigerVNC, SSH, and PAM — wrapped in a proprietary broker layer that handles session persistence, multi-server load balancing, and device redirection in a coherent way that none of the free alternatives manage out of the box. It is not glamorous software. It lacks GPU-accelerated display protocols, the free tier tops out at ten concurrent users, and it runs on a commercial licensing model beyond that cap. But for organizations that need reliable, multi-user, brokered Linux desktops without buying into a full VDI stack from Citrix or VMware, ThinLinc is the most operationally mature option available.

The core problem ThinLinc solves is deceptively hard: allow many users to each have their own persistent Linux desktop session, brokered across a farm of servers, accessible from thin clients or browsers, with local device resources (printers, drives, sound) tunneled cleanly into the session. Each individual piece of that has a free-software answer, but assembling them into a working system with reconnection semantics, load awareness, and a consistent client experience is where ThinLinc earns its keep.

Architecture: VNC All the Way Down

The TigerVNC Foundation

ThinLinc is not hiding the fact that it is built on VNC. Cendio is actually the primary corporate maintainer of the TigerVNC project, and TigerVNC handles the actual remote framebuffer transport inside every ThinLinc session. What ThinLinc adds on top is everything that VNC alone does not provide: session brokering, multiplexed SSH tunneling, user authentication integration, and client software that knows how to negotiate with the broker before connecting to the display.

Each active user session runs a dedicated TigerVNC server process on the agent host. The VNC protocol (RFB) handles the graphical stream and input, while SSH carries it all — every graphical channel, every redirection tunnel (sound, drives, printers, serial ports) is multiplexed over a single SSH connection per user. This means the only port that needs to be open through a perimeter firewall is port 22. The VNC servers themselves are never directly accessible; they bind to loopback or agent-internal addresses and are reached exclusively through the SSH tunnel that the ThinLinc session machinery establishes.

The VSM Master and Agent Split

The ThinLinc cluster is organized around two server roles: the VSM master (vsmserver) and one or more VSM agents (vsmagent). These can run on the same machine for a single-node installation, or be split across many machines for an enterprise farm.

  ThinLinc Client (native or HTML5)
          |
          | SSH port 22 (initial broker connection)
          v
  +------------------+
  |   VSM Master     |   <-- vsmserver process
  |  (broker/auth)   |       - authenticates user
  |                  |       - selects least-loaded agent
  +--------+---------+
           |
           | internal RPC (agent selection)
           v
  +--------+---------+     +------------------+
  |   VSM Agent 1    |     |   VSM Agent 2    |
  |   vsmagent       |     |   vsmagent       |
  |   TigerVNC/user  |     |   TigerVNC/user  |
  |   sessions       |     |   sessions       |
  +------------------+     +------------------+

  All graphical data tunneled over SSH from client -> agent
  Master redirects client to agent after authentication

The connection sequence works in two steps. The native client (or web client via the ThinLinc web access proxy) connects first to the master on port 22. The master authenticates the user against PAM, selects the agent with the lightest current load, and returns connection details for that agent. The client then opens a second SSH connection directly to the selected agent, which starts or resumes the user’s VNC session. From the user’s perspective this is invisible — one click, one desktop.

Session Brokering and Load Balancing

The Cluster and Subcluster Model

A ThinLinc installation with multiple agent servers is called a cluster. The master maintains awareness of all agents, their current session counts, and their availability. Load balancing for new sessions defaults to fewest-sessions-first: the agent currently hosting the smallest number of active sessions wins. If agents have heterogeneous hardware, weight parameters allow you to bias placement — a node with twice the RAM can be given twice the weight, causing the master to route proportionally more sessions to it.

Beyond simple weighting, ThinLinc supports subclusters: named groups of agents that are bound to specific users or groups. This is the mechanism by which you can segregate workloads — give the visualization-GPU nodes only to the molecular dynamics research group, route general users to the thin compute tier. Each subcluster has its own agent list, and users are placed into subclusters via group membership configured in /opt/thinlinc/etc/conf.d/vsmserver.hconf.

1
2
3
4
5
6
7
8

# /opt/thinlinc/etc/conf.d/vsmserver.hconf (fragment)
[/vsmserver/subclusters/default]
agents = agent1.example.com agent2.example.com agent3.example.com
...

[/vsmserver/subclusters/gpu]
agents = gpu1.example.com
...

Session Persistence and Reconnection

One of the more operationally important behaviors is that ThinLinc keeps sessions alive across disconnections. When a user closes the client without logging out, the VNC server and the entire desktop session remain running on the agent. When they reconnect — from the same machine, a different machine, or a browser — the master routes them back to the agent hosting their existing session. The session comes back exactly as they left it, open applications and all.

The master tracks session ownership and location in a central session database. It also enforces that all sessions for a given user land on the same agent to avoid conflicts with applications that hold exclusive locks on home directory files (.ICEauthority, GNOME session sockets, and so on). If the assigned agent becomes unavailable, policy determines whether the user gets a new session on a different agent or is told the cluster is unavailable.

Installation and Configuration Basics

Installing the Server Bundle

Cendio distributes ThinLinc as a self-extracting bundle rather than via distribution packages. The download is a tarball containing RPM and DEB packages plus the install-server script.

1
2
3
4

# Extract and run the server installer
tar xzf tl-4.x.x-server.tar.gz
cd tl-4.x.x-server
sudo ./install-server

After installation, the interactive setup wizard is invoked:

1

sudo tl-setup

tl-setup handles the license import (you drop the free community license file here), configures the VSM master and agent parameters, and verifies that SSH is functional. For single-node installs the whole process takes under five minutes. For a multi-node cluster you run install-server on each agent machine, then on each agent add the master’s hostname to the agent’s configuration so it registers correctly.

Network Ports

For the native client, SSH on port 22 is the only external requirement. The web client (ThinLinc Web Access) additionally needs port 300/TCP open, which is where the HTTPS-fronted web proxy listens. The administration web interface runs on port 1010/TCP and should be firewalled to management networks.

Port 22/TCP    — SSH; all native client traffic, all session data
Port 300/TCP   — HTTPS; ThinLinc Web Access (HTML5 client)
Port 1010/TCP  — HTTPS; tlwebadm administration interface

Between master and agents, the vsmagent process listens on port 904/TCP by default for the internal RPC channel the master uses to query session state and issue placement decisions. This port must be reachable from the master to each agent but does not need to be exposed externally.

The License File

Out of the box, the installed server ships with three Community License slots. Cendio provides a free download of a Community License file that raises the concurrent session limit to ten. You place the license file in /opt/thinlinc/etc/ and either restart vsmserver or load it through the web administration interface. No registration or account is required for the free community license, which is a notable difference from tools like NoMachine that gate free use behind an account and specific product editions.

The Web Access Client and Native Clients

HTML5 Web Access

ThinLinc Web Access is a browser-based client that presents the full Linux desktop session through any modern browser without plugins. It connects to the master’s port 300 via HTTPS, handles authentication, and renders the VNC framebuffer using HTML5 canvas. The user gets keyboard and mouse input, clipboard integration, and audio output (in supporting browsers).

The HTML5 client is functional but represents a narrowed feature set compared to the native client. Most notably, local device redirection is largely unavailable through the browser: local drive/folder mounting, serial port redirection, and local printer tunneling all require the native client. The browser’s sandboxing model prevents the kind of direct host access these features need. Audio playback works in most browsers; audio capture (microphone redirection) has variable support.

This matters for deployment planning. Environments where users will primarily authenticate from locked-down workstations or Chromebooks can rely on the HTML5 client for basic access. Environments where local printer or drive access is a requirement need either native client deployment or a different strategy.

Native Clients

Cendio ships native client binaries for Linux, Windows, and macOS. The Linux client is typically installed via the distribution package from the ThinLinc download page. The Windows and macOS clients are conventional installers. All three support the full feature set: local drive export (the client’s local filesystem is mounted inside the session as a SFTP-backed share), local printer tunneling via thinlocal, serial port redirection, audio input/output, and clipboard. Smart card forwarding for regulated environments is also supported through the native clients.

The native client connects via SSH, which means it behaves well through NAT and firewalls, benefits from SSH host key verification for authenticity, and can be augmented with SSH certificates or two-factor authentication via standard PAM modules.

Device Redirection

Local Drive and Folder Access

When a user connects with the native client, their local drives appear inside the session under /var/opt/thinlinc/mounts/ (or a path configured by the admin). This is implemented via SSHFS — the client exports its local filesystem over the SSH session, and the agent mounts it. The result is that users can open files from their laptop directly in applications running on the server without copying anything.

Printer Redirection

ThinLinc ships a helper called thinlocal, which is a virtual CUPS printer queue installed in the session. When a user prints to thinlocal, the print job is serialized, tunneled back through the SSH connection to the client, and handed to the client’s default local printer. This approach sidesteps the need for the server to know anything about the client’s printer drivers or network printer configuration.

Audio and Serial Ports

Audio is tunneled bidirectionally. The session uses a PulseAudio sink that routes audio data through the SSH connection to the client, where it plays through the local sound device. For environments with audio-heavy applications (medical imaging software with alert sounds, for example) this works reliably over LAN and acceptable over low-latency WAN.

Serial port redirection allows up to two client-side serial ports to be exposed inside the session. Use cases include scientific equipment (lab instruments, CNC interfaces) and legacy industrial hardware that expects a serial connection. This is a relatively unusual feature for a remote desktop product and reflects ThinLinc’s history in industrial and scientific computing environments.

Session Shadowing

Shadowing allows a privileged user (a support technician, instructor, or administrator) to connect to and observe — or interact with — another user’s active session. Configuration lives in /opt/thinlinc/etc/conf.d/shadowing.hconf. The shadowing_users parameter lists accounts or groups permitted to shadow others. The shadowing_mode parameter controls the end-user experience: reject denies all shadow requests, silent allows shadowing without notifying the session owner, notify shows a notification, and ask prompts the session owner to approve the request.

1
2
3
4

# /opt/thinlinc/etc/conf.d/shadowing.hconf
[/shadowing]
shadowing_users = support helpdesk
shadowing_mode = ask

Real-World Use Cases

HPC Login and Visualization Nodes

This is ThinLinc’s native habitat. HPC centers have always had the problem of users who want to run graphical applications — ParaView, VisIt, MATLAB, Chimera, VMD — on the cluster without transferring terabytes of data to a local workstation. The traditional answer was X11 forwarding, which is painful over WAN and falls apart entirely for GPU-rendered output.

ThinLinc fits directly into this model. Login nodes running vsmserver and vsmagent become graphical entry points to the cluster. Users connect with the ThinLinc client and get a full desktop running on the same host that can submit jobs to the SLURM scheduler or launch interactive sessions on compute nodes. For sites with dedicated visualization hardware, the subcluster feature routes users with GPU-heavy visualization needs specifically to nodes equipped with NVIDIA cards. Data stays on the cluster filesystem. Nothing is transferred except the graphical stream.

Several large HPC installations operate this way openly: LUNARC at Lund University, the HPC facilities at DTU Physics, the Oak Ridge EXCL facility, and the University of Chicago’s Research Computing Center all use or have used ThinLinc as their interactive desktop gateway.

University Computer Labs

The thin-client lab scenario is straightforward: install ThinLinc server on a few beefy servers, deploy thin client hardware or repurpose old desktops running the ThinLinc client, and all compute lives on the server. Software licensing is simplified because all sessions run on a controlled set of server hosts. Disk images do not need to be managed per workstation. A student who starts a long-running analysis on a lab machine and leaves can reconnect from a different machine and resume the session.

Regulated Environments and Data Governance

Healthcare, finance, and defense environments sometimes require that data never leave a controlled boundary. ThinLinc’s model — all processing and data storage on the server, only the display protocol traversing the network — satisfies this requirement architecturally. Combined with SSH certificate authentication, smart card forwarding, and PAM integration for two-factor auth, ThinLinc can be deployed in environments with strict controls around endpoint compliance.

Licensing Model

The Free Tier

The free Community License supports up to ten concurrent users. The server bundle ships pre-activated with three concurrent session slots, and a downloadable license file (no account required) raises this to ten. For small teams, homelabs, academic research groups, and pilot deployments, ten concurrent sessions is workable. The free license carries no feature restrictions beyond the session cap — every feature available in the commercial product works the same way.

Commercial Subscriptions

Beyond ten concurrent users, ThinLinc requires a paid subscription. Subscriptions are priced per concurrent user on annual, three-year, or five-year terms, with longer commitments receiving a discount. Volume tiers reduce the per-user cost as the user count increases. Support levels vary: Standard subscriptions include a two-business-day response SLA, Premium subscriptions provide one-business-day priority response. Non-profit organizations qualify for a twenty percent discount.

Cendio does not publish per-seat prices on their public pricing page without a quote request, which is a common frustration for administrators trying to do budget planning. The model is opaque in this regard, which is worth acknowledging honestly. The only reliable way to get numbers is to contact Cendio sales directly or request a quote through their website.

Comparison: ThinLinc vs. the Alternatives

Understanding where ThinLinc fits requires an honest look at the alternatives. The table below covers the most common comparators for Linux VDI:

Where ThinLinc Wins

The multi-user brokering and farm management story is genuinely better than any free alternative. X2Go has no concept of load balancing across servers; users connect directly to a named host. Plain VNC has no brokering at all. xrdp handles session management per-host but provides no cross-server coordination. ThinLinc’s master/agent architecture is the only free-or-cheap option where you can point a fleet of users at a single hostname and have the system distribute them intelligently across a server farm.

Session reconnection is also more reliable than X2Go in practice. X2Go reconnects frequently fail with certain desktop environments (particularly GNOME on Red Hat derivatives), and startup times can run ten seconds or longer. ThinLinc reconnects are near-instantaneous because the VNC server process is already running — the client is just re-attaching.

Where ThinLinc Loses

NoMachine’s NX protocol has meaningfully better performance over high-latency WAN than anything VNC-based. NX was specifically designed for compression and latency tolerance; TigerVNC’s Tight and ZRLE encodings are good but are not in the same class over a 150ms+ round trip. If users are routinely connecting from across continents or from mobile connections with variable latency, NoMachine Enterprise will feel smoother.

ThinLinc also has no hardware-accelerated display path. GPU-rendered OpenGL applications on the server render to a software framebuffer, which gets compressed and transmitted. For visualization workloads this is a ceiling — it works, but it does not leverage NVIDIA’s VirtualGL or NVFBC frame capture. Environments with heavy 3D workloads should evaluate VirtualGL separately or consider whether a protocol like NICE DCV or HP RGS is more appropriate.

The proprietary broker layer is also a legitimate concern. The underlying VNC and SSH components are open source, but the vsmserver and vsmagent binaries are closed-source commercial software. If Cendio were to disappear or dramatically change pricing, an organization running ThinLinc at scale has no path to maintaining the brokering layer independently. This is an honest risk, though Cendio has been actively developing ThinLinc since 2003 and the product shows no signs of abandonment.

Verdict

ThinLinc is the right answer for a specific and important problem: you need many users to have persistent, brokered Linux desktop sessions across a server farm, you want the whole thing to work through a browser or a native client without VPN gymnastics, and you are operating at a scale where ten concurrent users is either sufficient (free tier) or you are willing to pay for the commercial license. The HPC login-node use case is almost tailor-made for it, and the number of university and national lab deployments is a testament to this fit.

If you need fewer than ten concurrent users, ThinLinc is free with no registration, and the setup experience is genuinely better than assembling an equivalent system from VNC, SSH tunnels, and home-grown session management. If you need more than ten, the licensing model is opaque and contact-sales, which is annoying, but the product itself is solid.

Use NoMachine if high-latency WAN performance is the primary driver. Use X2Go if you need a completely free and open system and do not need farm-level load balancing. Use plain xrdp if your users primarily need a simple single-server Linux desktop accessible via standard RDP clients and you have no need for session roaming or cross-server brokering. None of those alternatives solve the multi-server brokering problem — that remains ThinLinc’s strongest unique capability.

Sources

• ThinLinc Free Usage — Cendio
• ThinLinc Buy/Pricing — Cendio
• ThinLinc Architecture — ThinLinc Administrator’s Guide
• ThinLinc Technical Overview — Cendio
• TCP Ports on a Master Server — ThinLinc Administrator’s Guide
• TCP Ports on an Agent Server — ThinLinc Administrator’s Guide
• Parameters in /vsmserver/ — ThinLinc Administrator’s Guide
• Clustering — ThinLinc Administrator’s Guide
• Shadowing — ThinLinc Administrator’s Guide
• Accessing Client Resources — ThinLinc Administrator’s Guide
• Local Printer Support — ThinLinc Administrator’s Guide
• ThinLinc Server Quickstart Guide — Cendio
• Intuitive Graphical Access to HPC — Cendio
• Using ThinLinc to Access HPC Systems — Cendio Blog
• ThinLinc as an Alternative to TigerVNC — Cendio Blog
• ThinLinc as an Alternative to X2Go — Cendio Blog
• LUNARC HPC Desktop Documentation — Lund University
• ThinLinc at EXCL — Oak Ridge National Laboratory
• Is ThinLinc Available for Free Usage? — ThinLinc Community Forum
• How Does ThinLinc Licensing Work? — ThinLinc Community Forum