If you don’t mind, we’d love to chat anyway. It’s super important for us to fully understand these types of requirements, as it helps determine the future direction of ThinLinc.

No worries if not, but if you’d like to, please send us through an email and I can set you up with our Product Owner @CendioOssman.

As William mentioned, ThinLinc will display that error when attempting to start a new session with a different start command than what an existing session has. You should be able to check what command line the session is running with using tools like ps or tl-session-param.

PS, you are correct that the menu used for tl-single-app comes from Openbox.

Unfortunately we’re not experts on Pangolin/Traefik/Caddy so probably won’t be much help there. You’d have to reach out via the relevant channels.

Probably the easiest way forward here - assuming you only have the ThinLinc server installed on one machine behind the router - is to not bother with a reverse proxy, and just forward port 300 instead. This should work, provided you set agent_hostname correctly. If it doesn’t, please provide a detailed description of the error you’re getting and we’ll try to help.

The scripts I’m calling adjust the policy.json for Chromium (URLallowlist, etc.) and then finally run Chromium with the corresponding URL.

So, I only have one ThinlincServer (with multiple agents) with different options. Having the student choose a profile isn’t an option either.

There are several ways to exit the terminal and its application: closing the tab, closing the window, using the menu from “openbox(?) - minimize session, quit/logoff session”.

And, of course, shutting down the terminal. These exits are obviously handled differently and therefore don’t always respond to “-f terminate”—I can’t say whether this is a bug.

I’m currently working around it by allowing multiple sessions and also setting MaxDisconnectionTime. Fortunately, I have the resources.

In any case, thank you very much; without Thinlinc, administration would be much more difficult. Thanks for the great work!

I suspect that would rid you of the “You’re not allowed to create any more sessions” problems.

You could create a profile in /opt/thinlinc/etc/conf.d/profiles.hconf (on the agent) like this:

[/profiles/moodle]
xdg_session=
name=Moodle
description=Moodle session for exams
icon=terminal.svg
screenshot=terminal-ss.png
cmdline=tl-single-app /opt/kiosk/kio-open.sh
testcmd=type /opt/kiosk/kio-open.sh
description_from_testcmd=false

By making sure only a single profile is listed in order your users won’t get a choice:

order=moodle

If you wish to disable the profile chooser intro, it can be done with:

show_intro=false

The -f terminate option could be approached differently by, for example, limiting how long a disconnected session is allowed to live. In /opt/thinlinc/etc/conf.d/vsmagent.hconf (on the agent) you can add -MaxDisconnectionTime to xserver_args:

xserver_args=-br -localhost -verbose 3 -MaxDisconnectionTime 60

See the following parts of our admin documentation:

Thank you for your response!

Sending the raw, uncompressed, USB data stream has been out of the question since day one of this project based on those exact bandwidth concerns you raise. As far as I’m aware, we are yet to decide on a codec to use for the network transport. Regardless, we are well aware of the fact that a handful of uncompressed camera streams will easily saturate a 1GbE NIC and will have that solved before release

But it would of course be better to have a native webcam support in ThinLinc to route the video signal from a webcam transparently into the ThinLinc session. However, can you perhaps already share some more technical details on the actual solution you are about to implement (h264 streaming or direct ip-based USB forwarding?) since I fear that in case 20-30 users would start a webcam session in their ThinLinc session, the bandwith of the underlying server would quickly be exhausted if the video signal forwarding would just transparently forward the signal to the server.

So some more technical details in advance would be great! Thanks!

As for the traefik (and caddy) config files, that is what pangolin spits out.

What thing did you configure in ThinLinc Web Admin?

If you’re not going to use our reverse proxy feature:

Port-forwarding port 300 is not enough, you still need to set agent_hostname. After logging in, Web Access will redirect to the agent using what’s specified in agent_hostname (even if the agent and master are on the same machine), this is the critical step. If I correctly understand what you’re trying to achieve, I believe you should set agent_hostname to the IP or hostname of your router.

We know that this is a feature that has been requested by many users. E.g. in the thread How To: Get USB cameras working through thinlinc, or Video forwarding. We’ve also tracked this in our bugzilla for a long time.

This project is done in collaboration with one of our ThinLinc customers, who are co-financing this development with Cendio.

If everything goes well, this will be included in ThinLinc 4.22.0 at the end of this year. At that point, it will work as smoothly as all other features in ThinLinc, and on all platforms. Users will simply need to click a box in the client to share their camera.

Our goal is to have no need for manual configuration on the server, no extra kernel modules, or any such magic that might disrupt stability or compatibility.

Stay tuned as we’ll share more updates on how this project progresses.

Also, congrats on launching in the USA!

I’m not familiar with Pangolin, but it does appear to support raw TCP/UDP streams (at least from 1.0.0-beta.9).

Are you running ThinLinc on a single machine, i.e. master and agent on the same server? If so, I think you should be able to get away with just forwarding port 300 on your router, and not bother with the reverse proxy.

@samuel or @Zeijlon does this sound right?

I am incredibly proud to announce a major milestone for Cendio: the official launch of THINLINC USA INC.

To better serve the growing demand from our North American users, we have established a dedicated local presence. Led by HPC expert Robert Henschel, this expansion allows us to provide direct, on-shore support and simplified procurement for ThinLinc. We are the real Linux Remote Company, and we are here to own the future of high-performance remote computing in the U.S.

Read the brief announcement and all the details on our blog:
Cendio Establishes Local Operations in the United States

Best regards,

Johan Igheimer
CEO, Cendio

Our ThinLinc cluster is using AutoFS service to map users storage data to their thinlinc sessions. However, we’ve noticed issues like outstanding “disconnected” user sessions interrupting our ceph storage access. Curious if enabling “browse_mode” in /etc/autofs.conf helps the load on the ceph cluster and maybe remediate this issue. Very clueless on the effects of automounting ceph storage on thinlinc cluster so any shared experiences are greatly appreciated.

Thanks!

yes, i always use the same parameters because its associated with an icon (the only one) on the desktop.

when i terminate the session “regulary” (close the tab oder window) the session is in status (tlctl ) connected but not a single process of that session is running on the agent server!

when i shutdown or reboot the terminal the processes of that session are still running on the agent and the connection fails with “not allowed anymore sessions”. the staus before the reconnection is on conected and after the error it changes to diconnected.

isn’t a little bit strange?

regards j.

In case you have a session running a specific program (through the -s option), you will not be reconnected to that same session unless you specify the same -s option as the existing session was started with. If another (or no -s option) is specified, ThinLinc will try to create a new session instead. This will result in the error you are describing with the default configuration of allowing at most one session per user.

Does reconnecting to the session work if done with the same -s option specified as when the session was initially started?

I don’t think we are actually starting our ThinLinc sessions through systemd, but we are for sure doing something to make our sessions visible to logind.

On most systems, this is the responsibility of the session stack in PAM (by including pam_systemd.so).

wilsj:

In this case, that means assuming that the graphical session is started through systemd, which will be the case for sessions started both by ThinLinc and modern display managers.

I don’t think we are actually starting our ThinLinc sessions through systemd, but we are for sure doing something to make our sessions visible to logind. I just wanted to add this clarification since we currently do not have a hard dependency on systemd. It’s possible to run a ThinLinc server on a non-systemd system.

That is actually fine! The main reason for adding the check is that we want to improve the user experience for new/novice users that are testing out ThinLinc for the first time.

Gnome and some other DEs don’t work well in a multi-session context, and we would like to avoid creating broken sessions when, for example, a user is testing ThinLinc on their local machine.

I’ll describe the setup in a bit more detail; perhaps I’ve made a mistake.

I’m connecting from an IGEL terminal using ThinLINC 4.16 to a ThinLINC server 4.19, which then forwards to a 4.19 agent.

I start the connection with:

10.0.29.225 -f terminate -s “tl-single-app /opt/kiosk/kio-open.sh”

userid is the terminal name; the password is provided by the setup.

kio-open.sh is a script that ultimately starts Chromium for a Moodle session (for exams).

If the session is terminated normally (window or tab close), then

the output of tlctl session list is “connected.” Reconnecting works without any problems.

After shutting down the terminal and after rebooting and reconnecting, tlctl session list shows “disconnected” and the error “(You’re not allowed to create any more sessions)” appears.

In the master’s log file:

2026-02-26 09:21:55 DEBUG vsmserver: Handling method ‘create_user_socket’ from (‘127.0.0.1’, 41830)
2026-02-26 09:21:55 DEBUG vsmserver.session: User with uid 3005292 requested a socket
2026-02-26 09:21:55 DEBUG vsmserver: Handling method ‘create_user_socket’ from (‘127.0.0.1’, 41844)
2026-02-26 09:21:55 DEBUG vsmserver.session: User with uid 3005292 requested a socket
2026-02-26 09:21:55 DEBUG vsmserver: Handling method ‘get_capabilities’ on socket owned by uid 3005292
2026-02-26 09:21:55 DEBUG vsmserver: Handling method ‘create_user_socket’ from (‘127.0.0.1’, 41848)
2026-02-26 09:21:55 DEBUG vsmserver.session: User with uid 3005292 requested a socket
2026-02-26 09:21:55 DEBUG vsmserver: Handling method ‘get_user_sessions’ on socket owned by uid 3005292
2026-02-26 09:21:55 DEBUG vsmserver.session: User with uid 3005292 requested a list of his/her sessions

2026-02-26 09:21:55 DEBUG vsmserver: GetUserSessionHandler: List of groups: [3005214]

I then have to kill the sessions with tlctl.

Any idea what I’m doing wrong?

From a ThinLinc perspective, turning off the terminal should have essentially the same effect as disconnecting. So I’m surprised you’re not able to reconnect to the existing session.

After turning off the terminal, does tlctl session list still show your session?

You can also check /var/log/vsmagent.log on the agent server. If there are any error messages, please feel free to post them here.

Naturally, there are ways to circumvent this check. Our belief is that this should be relatively rare in production environments though. Please @Zeijlon, correct me if I’m wrong!

What to do in this situation? I can’t terminate the session with tlctl, because it should be done automatically

Any ideas?

Our very own Robert Henschel (@RobertHenschel) is attending alongside Hugo Hernandez and the spinTwo team. If you’re at the BioScience Research Collaborative (BRC) today or tomorrow, come find them to chat about Linux VDI, high-performance visualization, and how we’re working with spinTwo to streamline HPC workflows.

See you in Houston!

• Dates: February 24–26, 2026

• Location: BioScience Research Collaborative (BRC), Rice University, Houston, TX.

On the ThinLinc side, you should make sure you’ve set:

• /webaccess/login_page to be the public-facing URL of your proxy server
• /vsmagent/agent_hostname on each agent to be the hostname of the agent
• /webaccess/trusted_proxies to contain the IP address of your proxy server

You would then have to adapt the Nginx configuration in the documentation for Pangolin (or use Nginx instead). Notably, you need to make sure that the path /connect/<agent_hostname>/ is handled by your proxy server.

I realise this is quite involved for smaller installations but hopefully this gets you on the right path.

hooray. it did help

Thanks a lot

Oskar

I use version 4.20.0.

After having read through what you have sent me, i still do not understand how to put ThinLinc behind a remote proxy (specifically Pangolin because it uses a webui to configure “resources”)

First off, which version of ThinLinc are you running? I ask because the latest version (4.20.0) has explicit support for reverse proxy.

I run a computer club at my school. I am looking to have a TL server at home, and access the server from the school computers (we are NOT admins) using the web access (port 300). I tried reverse proxying port 300 using Fossorial Pangolin, but was not able to access the server (aka it said redirection failed). How do i do this, optimally without using port forwarding (it is OK because i trust my students enough to let know the city i live in but it’d be better not to use it for load and security reasons)?

Unfortunately this is a known bug in the current version of ThinLinc. It has been fixed for the next version, but until then, you can try installing via the text-based installer:

$ DISPLAY= /opt/thinlinc/sbin/tl-setup

Hope that helps.

openssh-server installed.
port 22 opened - can ssh to the machine

ThinLinc server ( .deb) installed

/opt/thinlinc/sbin/tl-setup ends with a

2026-02-19 18:26:57,804: Configuring CUPS…
2026-02-19 18:26:57,804: Adding ‘nearest’ printer queue…
2026-02-19 18:27:02,852: Adding ‘thinlocal’ printer queue…
2026-02-19 18:27:07,795: Done
2026-02-19 18:27:14,425: Traceback (most recent call last):
2026-02-19 18:27:14,425: File “/opt/thinlinc/modules/thinlinc/tlsetup/firewall.py”, line 77, in Oooo0o0oO0
2026-02-19 18:27:14,425: “yes” if iI111iiIi11i [ o0o . name ] . get_active ( ) else “no” )
2026-02-19 18:27:14,425: ~~~~~~~~~~~~~^^^^^^^^^^^^^^
2026-02-19 18:27:14,425: KeyError: ‘OpenSSH’

Any hints are highly appreciated
Thanks
Oskar

I’ve added this bugzilla entry to track it:

For example if I disable the display manager and use startx + .xinitrc to start a local X session, even if I prepend exec /usr/bin/i3 with export XDG_SESSION_TYPE=x11 (to make applications that look at this variable happy), loginctl will report my session as a tty type.

That shouldn’t be a problem if I swap i3 for tlclient though: the ThinLinc agent will then start it’s own local X session, that will be reported as an x11 type. (And one doesn’t even need to mess with XDG_SESSION_TYPE in that case: it will be set to x11 and that’s what the ThinLinc clients will see.)

@wilsj @Zeijlon am I missing something?

That AVC is not familiar to me. What distribution is this from, @JBL?

This is required for having a cluster of multiple ThinLinc servers, as the machine keeping track of all the alive sessions (the master(s)) may be separate from the machine(s) actually hosting the sessions (the agents).

In this case, the wording (and WARNING log level) is probably a bit harsh, as this is expected when a user has logged out. There is now an entry for making the logline less scary in our issue tracker:

sudo pacman -S plasma-x11-session

Here you find more information on the Omniverse Documentation.

If you’ve ever wondered where the “boundary” of an organization lies, this one’s for you.

The Question:
“We are a small team, but we’re part of a massive government entity. Does the 10-user limit apply to just our team, our department, or the entire government? Also, can we have 100 servers with 1 user each?”

The Straight Answer:

1. On Instances vs. Humans: It’s okay to install 100 servers software if you like. However, the limit is based on the people. You are not allowed to have more than 10 concurrent users connected at the same time across all those installations.
2. On the “Organization” Boundary : We look at the organization as a whole. To use a Swedish example: think of IKEA. If a small department in southern Sweden uses ThinLinc for 10 users under the Community License, that counts as the “10 free seats” for the entire IKEA organization worldwide. The same logic applies to a federal government.

Why we’re telling you this:
At Cendio, we aren’t like the “Big Tech” giants. We don’t want to hide behind 500 pages of legal jargon or “gotcha” clauses. We believe in:

Transparency: No robots, no confusing EULAs—just clear rules.
Flexibility: Because we are a tight-knit team, we have short decision paths. If the standard model doesn’t fit your unique government or corporate structure, we can be flexible and build a commercial model that actually makes sense for you.
Proven Success: We already have government customers globally using ThinLinc with high satisfaction.

The Takeaway: If you’re a small team in a giant organization, don’t stay in the “legal gray zone.” Reach out! We’re happy to jump on a call, talk through your architecture, and find a way to make ThinLinc work for your specific needs.

Otherwise from a user perspective, the sessions were behaving as expected.

For now I simply added a policy to allow this, but I’m interested to know if this is a common issue and if there’s a better way to address this.

From what I can tell, process 123 indeed doesn’t exist anymore, for a good reason: it corresponds to the previous tl-session, which from a user perspective ended as expected.

The log entry seems to be generated by an obfuscated /opt/thinlinc/modules/thinlinc/vsm/handler_verifysessions.py.

What could be reasons for ThinLinc believing that the previous session should be alive?