Knowledge Base
Searching in : Article
ID: AR01W01265
Applies to: NoMachine Server
Added on: 2025-01-10
Last Update: 2025-08-11

How profile rules work in v9

For those server types supporting profiles, rules allow to manage users' access to features and services on the local host and on the nodes, in case of multinode environments. They can be applied to specific users, groups of users, individual nodes or groups of nodes. As an administrator, you can disable features and services by adding rules for each item individually or by using the "all" rule to disable all features or services at once. Afterward, you can selectively enable the required feature(s) or service(s).

Profile rules are all enabled by default, except "manual-node-selection" and "enable-logout-on-disconnect", which are disabled by default.

It's possible to disable all rules for a given class:

nxserver --ruleadd --class session --type all --value no
nxserver --ruleadd --class service --type all --value no
nxserver --ruleadd --class feature --type all --value no

Setting type 'all' overrides the default values of the rules, but it doesn't override a profile rule set by the administrator. 

For example, if the administrator has already set:
nxserver --ruleadd --class service --type server-file-transfer --value yes 

the following rule will not override it:
nxserver --ruleadd --class service --type all --value no

Both rules will work concurrently, i.e. all services are disabled except sending files from server side to users (server-file-transfer).

You can restrict action of the rule to a group of users (system groups are supported) or in case of multinode environments, to a group of nodes.

How rules are resolved
Rules are evaluated from the most strict one (rules set on per-user basis and per-node basis have priority) to the most general one. The most strict rule is the most important and it will be used if all its arguments match the current request to connect a session (user, node, users group, nodes group).
 

Propagation of rules in multinode environments
In case of the Enterprise Terminal Server and Enterprise Terminal Server Cluster, rules set on the server applies automatically to the nodes. For example: 

i) nxserver --ruleadd --class service --type server-file-transfer --value yes --group testers
 
will allow file transfer from remote only to members of 'testers' group. 
 
ii) nxserver --ruleadd --class service --type server-file-transfer --value yes --node-group Testdrive
 
will allow file transfer from remote only from those nodes that belong to the node group 'Testdrive'. 
 


For Cloud Server (CS) environments, rules set on the CS can be propagated to the nodes.

Cloud servers accepts the --propagation class, which is a special class that extends rules set on the nodes or override them.

Format is:
nxserver --ruleadd --class propagation --type all-session --value no
nxserver --ruleadd --class propagation --type all-service --value no
nxserver --ruleadd --class propagation --type all-feature --value no

To disable only one type of any of the available classes, specify it with the --type option, like the following.

1) Forbid users of system group 'group5' to connect to the NoMachine virtual desktop of another user. This applies
to all Linux nodes only:
nxserver --ruleadd --class propagation --type shadow --value no --group group5

shadow is an item of class 'session'.

2) Forbid all users to forward USB devices from node3 to their local device:
nxserver --ruleadd --class propagation --type server-usb-sharing --value no --node node3

server-usb-sharing is an item of class 'service'.

3) Forbid user1 to copy&paste from remote to local and vice-versa. This applies to all nodes:
nxserver --ruleadd --class propagation --type server-clipboard ---value no --user user1
nxserver --ruleadd --class propagation --type client-clipboard ---value no --user user1

server-clipboard/client-clipboard is an item of class 'feature'.

Other some practical examples

1) Extend rules set on the node

Node node1 has this rule set:
nxserver --ruleadd --class service --type client-file-transfer --value no

or it has these rules:
nxserver --ruleadd --class service --type all --value no
nxserver --ruleadd --class service --type server-file-transfer --value yes



In both cases client-file-transfer is disallowed on node1. In the first case because of a separate rule, in the second case because of the 'all' rule.

The CS propagates this rule:
nxserver --ruleadd --class propagation --type client-file-transfer --value yes --group group1

If the connecting user belongs to group1 and connects through the Cloud Server, the rule above overrides the rule set on the node (either that of  'client-file-transfer no' or that of 'all no') and bidirectional file-transfer is allowed.

If the connecting user doesn't belong to group1, transferring a file from local computer to remote (client-file-transfer) is not allowed and only file transfer from the remote host to the user's computer is allowed. The same occurs if the user connects directly to node1.


2) Overrides rules of the node

Node2 has these rules set:
nxserver --ruleadd --class service --type server-file-transfer --value no --group group1
nxserver --ruleadd --class service --type client-file-transfer --value no --group group1

and the CS propagates this rule:
nxserver --ruleadd --class propagation --type all-service --value yes

Since file transfer is a service, result is that bidirectional file transfer will be allowed on all nodes and for all users, also to members of group1, even if denied on the node.  Note that if users connect directly to node2, rules set on the node are applied and file transfer will be not allowed for those users belonging to group1 of users.

If CS propagates these rules to node2:
nxserver --ruleadd --class propagation --type all-service --value no --node node2
nxserver --ruleadd --class propagation --type server-file-transfer --value yes --node node2
nxserver --ruleadd --class propagation --type client-file-transfer --value yes --node node2

bidirectional file transfer will be allowed on node2. All the other services will be forbidden on node2.

List of available rules
Please consult the Guide of your NoMachine server type in the 'Installation' section at: https://www.nomachine.com/support/documents for a list of the available rules and how to use them.


Profile rules versus configuration files
For an easier management, it's recommended to choose to configure settings via profile rules or via configuration files (server.cfg/node.cfg), especially in case of multinode environments with a large number of nodes. 
 
With profiles it's possible to set rules on per-users/groups basis or apply them in multinode environments to specific nodes only.
 
Configurations in .cfg files apply only to the host where they are set.
 
If profile rules are set and the same item is also configured in the .cfg file, rules override the .cfg settings.  
 
In case above, it's important to notice that if the rule is for some reasons deleted, the .cfg setting will become effective. This could lead to unexpected behaviours, if it's not the default one. 
 
In case of multinode environments
Settings in .cfg on the Enterprise Terminal (Cluster) Server host or on the Cloud Server host don't apply to nodes. Settings in the .cfg on a node apply only to that node.
 
Profile rules set on the Enterprise Terminal (Cluster) Server host apply to all nodes or to the specified nodes and override cfg settings on such nodes. The same is for profile rules set on the Cloud Server host and propagated to the nodes.