Why are permissions so unnecessary confusing? // How does the system work?

Hello there,

I’m setting up a TS6 Server with docker at the moment. Everything is running fine, no technical issues.
Now that I’ve created some channels, I started with the permission system and…. oh boy…. that’s so confusing.

Why are there “global”, “virtual server”, “channel”, “groups”, “client” and “file transfer” settings, no matter where you look?
Server groups have “global”, “virtual server”, “channel”, “groups”, “client” and “file transfer” settings
Channel groups have “global”, “virtual server”, “channel”, “groups”, “client” and “file transfer” settings

I work in IT for many years, used many different applications, frontend, backend, server, Windows, Linux,…. so I am no beginner by any means.

But I am not able to realize the kinda easy task “a new client on the server can not join or see or inspect any voice channel (and members connected to that channel) unless an admin grants him a group/role to do so”.

There are many ways to implement a permissions and role system and I know that Teamspeak has an old and good reputation, but with TS6 there is the chance to build it convinient from scratch.
Having permissions by “channel groups” without the possibility to inherit permissions as a sub-channel… admins, be ready to click and click and click :smiley:

By now, I am happy with TS6, with the look, the voice quality, the customization and so on, it feels fresh an ready for 2026+. Once it is set up, it is nice for the clients. But admins could suffer.
And I know it is still in Beta, so lets wait for future releases.

Hey there,
I have been working with the TeamSpeak permissions system for over 12 years and I really like it. Sure, it’s not easy to get started, but it’s not as difficult as everyone always says. Once you understand the basic principle that permissions either have values that are compared with each other or true/false flag permissions, you actually have all the basics you need. This is because it is identical across server groups, client permissions, channel permissions, channel groups and channel client permissions. Each of these has unique use cases and is useful to have.

The order is Server Group < Client Perm < Channel Perm < Channel Group < Channel Client Perm. For example, if a user has a server group with 50 kick power and in their channel Test A they have channel client perm with kick power of 75, this overrides the 50 kick power of the server group!

Regarding your point about inheriting channel groups, this happens by default. If you create Channel A with Subchannel B and assign the channel group Admin to a new user in Channel A, then they will also be Admin in Subchannel B. There is also a special permission to stop inheritance: ‘b_channel_group_inheritance_end’.

For even more complicated things, you can then use skip and negate:

Skip

The “Skip” parameter can be set within the “Server Groups” and “Client Permissions” category only.
When selected, the “Client Permissions” or “Server Groups” permissions cannot be modified by the “Channel Groups” and “Channel” permissions.

Negate

The “Negate” parameter can be set within the Server Groups category only. When selected, the Server Group permission will check the same permission in other permission categories (“Channel Groups”, “Client Permissions” etc.) for the least greatest return value. (FALSE=0 or n<=x). This means that no single permission category has overwrite power stronger than the other categories, instead the category with the least return value will be selected as the dominant permission.

7 Likes

First of all: Big THANK YOU for your answers so far!

Probably, I am confused by the philosophy how permissions work in TS.
I am used to role/group models which are assigned to clients and channels.

The more I use it and talk about it, I understand what’s happening (crazy, right? sounds like “learning” XD )
And I can see the advantages this system comes with, for some use cases. And the flaws it has in others.

Please tell me if I’m on the right path here:
So, I have channel A with sub-channel A1,A2,A3 and channel B with sub-channel B1,B2,B3.
Now, I want to stay guests out of these channels until they get “member” status.
I know that I have to set i_channel_needed_join_power to, lets say, 10.
And if a client gets i_channel_needed_join_power of >=10 for this channels (either by server group or channel group or directly as client permission), he can join the channel.
But I have to set i_channel_needed_join_power for every single sub-channel by hand, right? And all other permissions as well, every time there is a new sub-channel.
Is there a way to copy the permissions from one channel to another? Or duplicate a channel?

In general, is it “bigger power beats lower power”?
Like - The channel has permissionA with power 10, so you need power >=10 in this channel.
Or - The client has i_client_kick_from_server_power of 50, so he can be kicked by someone with i_client_needed_kick_from_server_power >50? Or >=50?
It seems like this permissions come in pairs most of the time. i_xxxx_power and i_xxxx_needed_xxxx_power

This is correct, but you’ve got the examples wrong. It is the other way around

The needed permission is the one that resists a kick. Meaning this need to be 50 and the kick power need to be 50 or above.


Regarding your A1, A2 and A3 channels you may check out this post. If correctly set up this can be achieved by using channel groups, which only apply when the user tries to join the channel or when he is in the channel with the corresponding group. You would then need to manually move them into the channel and assign them the new group, that allows them to join the channel.

If you need any help regarding that, please post over there


You currently can not copy / apply settings for channels without using an automated system like a bot or Server Query.

2 Likes

Ok nice, thank you for all the tipps.

One last thing I need to get out of my head, what I am not capable to understand:
Why is it possible to set i_channel_join_power AND i_channel_needed_join_power in the permissions of a channel?
I think that’s the thing I am confused about. That you can set permissions which makes no sense (in my opinion).
Are these permission a Channel Admin gets for this channel?
Or are they simply “useless”, because a channel could never “join to a channel” but the set of permissions is fix for any entity?

Well, the short answer is that this is basically a side effect of how the permission system is architected internally.

There is one global permission registry.
Permissions are not bound to a specific semantic entity type. They can be stored in any of the permission containers (server groups, channel groups, clients, channels), and the evaluation engine later determines which values are relevant for the action being checked.

For the join check, the engine simply resolves:

  • effective i_channel_join_power of the client
  • i_channel_needed_join_power of the channel

and compares them.

A channel itself never “joins” anything — so assigning i_channel_join_power directly to a channel has no meaningful semantic purpose. But the system does not prevent it because permissions are stored generically, not semantically filtered by entity type.

In other words:

It’s not that the permission is “for a Channel Admin”.
It’s not that the channel can join something.
It’s simply that the backend uses a unified permission structure and the UI does not restrict logically meaningless combinations.

That design keeps the permission engine simple and consistent (no special cases per entity type), but it does make the UI appear more confusing than necessary.

It feels odd but it’s just a side effect of a generic permission model.

1 Like