fisherman

[fisherman]

Only thing that I could think of is not something with a hyphen type sudo /etc/NX/nxserver --nodegroupdel Nodes_Group_01.

Based on the copy of the output you did looks like the first “-” is longer than expected.
NX> 500 ERROR: Invalid command: '–-nodegroupdel'

[fisherman]

Hi,

in your case, you should use it like following
sudo /etc/NX/nxserver --ruledel --class node --type Nodes_Group_01 --group USERS_GROUP_01
sudo /etc/NX/nxserver --ruledel --class node --type Nodes_Group_01 --system

[fisherman]

Hi,

I have noted that in your command there was a missing hyphen, as you wrote -group instead of –group.

I would recommend checking these two articles for future reference
https://kb.nomachine.com/AR04U01198 and https://kb.nomachine.com/AR01V01217

Based on my understanding, you would like to block access to a specific group of nodes for all users and then allow for a particular group of users.

In this case, you can use the following:

Create node group:
sudo /etc/NX/nxserver --nodegroupadd NodeGroup_01

Add your node to the newly created node group.
sudo /etc/NX/nxserver --nodeedit IP_of_the_node --node-group NodeGroup_01

Disable access for all users to access hosts in the created node group.
sudo /etc/NX/nxserver --ruleadd --class node --type NodeGroup_01 --value no

Allow access for specify AD system group to access node group
sudo /etc/NX/nxserver --ruleadd --class node --type NodeGroup_01 --value yes --group DOMAIN\groupname_01

[fisherman]

Hi,

I just compared my installation with the mentioned article, and here are some general RAM requirements based on my test now on Ubuntu 22.04 where I used an example from the mentioned article :

Base RAM Usage of NoMachine processes:

• 170 MB – Base installation
• 17 MB per child server – To monitor availability
• 20 MB per connected user per node

Additional RAM for NoMachine WebPlayer when using a Web browser to connect to the server:

• 54 MB per session

Examples of RAM Usage:
Scenario 1: 10 nodes 5 concurrent users

• NoMachine Player: 170MB (base) + 170MB (connected nodes) + 100MB (connections) = 440MB RAM
• NoMachine WebPlayer:  170MB (base) + 170MB (connected nodes) + 100MB (connections) + 270MB (web) = 710MB RAM

Scenario 2: 500 nodes, 50 concurrent users

• NoMachine Player: 170MB (base) + 8.5GB (connected nodes) + 1GB (connections) = 9.67GB RAM
• NoMachine WebPlayer: 170MB (base) + 8.5GB (connected nodes) + 1GB (connections) + 2.7GB (web) = 12.37GB RAM

On version 8, NoMachine has a high-availability cluster.
– Master cluster peer that accepts incoming connections
– Slave cluster that remains in synchronization mode and takes over automatically if the Master Node goes down.

This ensures failover protection and reduces downtime in critical environments.

[fisherman]

The permissions you present in the ls output are correct.

[fisherman]

Hi

you can use IP only, see command

sudo ufw allow from 10.0.0.130

[fisherman]

Since you’ve already manually forwarded port 4000 on your router, utilizing UPnP for the same purpose might be unnecessary.

If you still want to use UPnP, I recommend enabling communication from your network or router to your Ubuntu Studio. You can do that by executing.
sudo ufw allow from 192.168.1.0/24

Replace 192.168.1.0/24 with the appropriate subnet for your network.
I would like to add a note that UPnP is using UDP port 1900 and TCP port 2869, and you might need to enable its communication depending on how your firewall is configured.
running
sudo ufw allow 1900/udp
sudo ufw allow 2869/tcp
sudo ufw reload

[fisherman]

NoMachine cannot autodetect devices on the other network segment, but there is a workaround that you can implement on the router.

To implement a workaround for this issue, the user must have network administrator privileges. They need to configure an mDNS forwarder, repeater, or proxy on the router, provided the router supports this feature.

This is necessary due to a fundamental limitation of the multicast protocol: each subnet uses the same multicast DNS address (224.0.0.251), which is not shared across subnets. For example:

• Subnet 192.168.1.0/24 uses the local mDNS address: 224.0.0.251
• Subnet 192.168.0.0/24 also uses the local mDNS address: 224.0.0.251

Without mDNS forwarding or proxying, devices in one subnet cannot discover or communicate with devices in another subnet via multicast.

[fisherman]

On NoMachine port 5353 is the broadcasting port, so you can not check it the way you tried. NoMachine uses NX port 4000 by default, or SSH port 22 for any enterprise product.

Please try the following steps:

1. Check accessibility:
   Use Telnet to test if either port 4000 or port 22 is accessible on the server:
   192.168.1.17 4000
   or
   telnet 192.168.1.17 22
2. Verify network routes:
   Ensure that your client’s subnetwork can access the server’s subnetwork, or confirm that the correct routes are in place to enable connectivity between the client and server.

Let me know if you need further assistance.

[fisherman]

It looks as if the application stderr is redirected so would be good if you could provide a .xsession-errors file from the user home /DV9G49/. In the logs, we can see that the application closes unexpectedly during startup.

Please also add localhost to the /etc/hosts file of the docker container as:
127.0.0.1 localhost

Check if starting the container with --cap-add=SYS_PTRACE can make any difference.

Then, please enable logs by executing sudo /etc/NX/nxserver --debug --enable all, reproduce problem and collect logs as well as including .xsession-errors file.

[fisherman]

Removing the NoMachine software from the picture entirely, we were NOT able to launch Debian Gnome desktop from a docker file. So, this is something that we cannot investigate further. Whilst, as we mentioned, XFCE runs fine.

Putting NoMachine back into the picture with XFCE, again everything works as expected. So you could possibly try with XFCE as well, as we recommended earlier.

However, the issue you are having with the /rhome/ folder is not clear to us. For NoMachine to work properly, the user which is connecting must have write permissions to the user’s specific home folder. We suspect that there is a system misconfiguration, but we cannot know where. So it might be that even with XFCE, you will not be successful because of the misconfiguration of user permissions.

We will wait for the logs in any case and check them.

[fisherman]

I have never tried to use and setup gnome to be started using docker containers. I feel that your issue is related to the docker configuration and not at all to the NoMachine. I have tried installing gnome in my docker container and could not start a gnome-session unrelated to the NoMachine. I used xvfb-run, and the session was failing with something related to dbus, I did not explore and debug more.

While I can confirm that I have tested xfce and Mate and they work very well.

sudo apt install xfce4 xfce4-goodies

and then edit /usr/NX/etc/server.cfg and set that NoMachine will start xfce4
DefaultDesktopCommand /usr/bin/startxfce4

[fisherman]

Upon reviewing our system configurations, I’ve noticed an issue with the permissions in the /rhome directory. Specifically, the home folder of DV9G49 appears to be owned by root with only root having write access.

Here’s a snapshot of the permissions:

root@workstation-analyst3:~# ls -la /rhome/
total 736
drwxr-xr-x 15 root root 4096 May 31 14:36 .
drwxr-xr-x 1 root root 4096 May 31 13:26 ..
drwxr-xr-x 2 root root 4096 May 23 16:03 DV9G49

However, upon further inspection, it seems that the correct permissions are applied in your home directory /home/DV9G49:

root@workstation-analyst3:~# ls -la /home/DV9G49
total 28
drwxr-xr-x 2 DV9G49 DV9G49 4096 Feb 27 14:52 .

To resolve this discrepancy, I recommend checking if your NFS mounting, if used, correctly applies permissions. If not, please ensure that the folder /rhome/DV9G49 is owned by the user DV9G49 and has write permissions for the same user.

Thank you for your attention to this matter. If you require any assistance or further clarification, please don’t hesitate to reach out.

[fisherman]

you can change PhysicalDesktopMode 1 in the /usr/NX/etc/server.cfg file

extracted part from the server.cfg file with explanation what each mode is doing:

# Set the interaction level for the session connected to the physical
# desktop:
#
# 0: View-only. The session is connected to the desktop in
#    view-only mode, i.e. the user can't interact with the
#    physical desktop.
#
# 1: Restricted. User connected to the physical desktop can
#    interact with the desktop except for resize operations.
#
# 2: Interactive. User connected to the physical desktop has
#    full interaction with the desktop.
#
#PhysicalDesktopMode 2

[fisherman]

Can you check nxserver --history if it gives you the details you need.

I extracted usage from the nxserver --help

--history
  [--verbose]
  [ --file <file>]
  [<sessionid>|<username>|clear]
  [--client-type] [--client-version] [--client-platform]
  [--stats]

[Author]

Posts