Mth

[Mth]

Hello.

The player logs had nothing really meaningful, so I think we need the server side logs here.

Please check the system logs. For mint system the /var/log/auth.log should
say if the logging attempt was blocked by the system (entries for nx:auth).

Also as the nx service uses su module for authorization, please provide us the /etc/pam.d/su module
configuration. Also please note that if authorization uses Kerberos tool, you need to specify it before
connecting in the player (connection details -> advanced).

And at last please provide the NoMachine server logs. As your server is on Linux, please refer to point
‘1.1. Server on Linux’ of the article
https://www.nomachine.com/DT10O00163

Please enable logs, try to connect and then gather the logs. Send them to us just like before.

/Mth

 

[Mth]

Hello

The problem here is a bit complicated. As you said, setting PhysicalDisplays key to ‘:10’ prevents the NoMachine from detecting your true desktop (which probably is on display :0, :1 or :1024 if you are using Wayland).

Then, as you say NoMachine is creating its own Xserver and starting the session there.

So now you have ‘physical session’ and ‘virtual session’ working on your system, so even when you unlock it on physical screen, it will not affect virtual.

The problem is however with virtual session and lock screen. It is a known issue with the new way gnome handles the sessions, and how it interacts with NoMachine virtual sessions, and right now unfortunately there is no solution, except for disabling the lock screen on the virtual session.

/Mth

[Mth]

Hello

I’m sorry, this forum seems to change double “-” signs to this big “–” when not written in code tags. The commands to use are:

sudo /usr/NX/bin/nxserver --useradd <username>
sudo /usr/NX/bin/nxserver --passwd <username>

But it seems this does not matter in this case.

I’m sorry I have not noticed before, but on that screenshot you sent you are in a completely wrong page.

This is not an connection attempt to the remote machine. This is an attempt to change settings on the server for the local machine.
If you click on this “lock icon” and the “Changes disabled”, you should get prompt for the local administrator account and password to enable the
settings changes, same if you try to change anything.

I am really not sure what is the case here, but to connect to another machine please use “New connection” instead of “Service status”
screen from the monitor tray icon, or use ‘nxplayer’ application.

/Mth

[Mth]

Hello

First thing about NoMachine config, the information you got is correct, when you set it like that:

#EnableUserDB 1
#
EnablePasswordDB 1

Even if you change the EnableUserDB key to 1, the whole line is still treated as comment line and ignored. You need to get rid of ‘#’ character for config line to be parsed.

Second, at the bottom of the config file, the Section “Server” and Section “STUN” are only when you are connecting to the server using web interface (usually through a web browser) and not NoMachine player application. And for standard usage the modifications here are usually
not required.

Also if you are using free version, the HTTP protocol is disabled, so those fragments can be simply ignored.

Then for the config file backups, I’m afraid there is no way to restore it in easy way. We provide some generic cfg.sample files, but the main .cfg are created during the installation procedure depending of operating system configuration. In other words, you can restore some of the keys by comparing
.cfg to .cfg-sample files, but the most important ones have to be created on installation.

And for the problem. Part of it of course may be that currently you have EnableUserDB key commented and by default it is set to 0. Although when EnablePasswordDB is set to 1 it should not provide the problem with login.

First what does EnablePasswordDB do. If it is set to 0, you can connect to the NoMachine server using any user account that is on that operating system by providing its username and system password.
When you set it to 1, by default you will not be able to connect at all.

So by doing ‘sudo /usr/NX/bin/nxserver –useradd *****’ you have provided the NoMachine database with the user.
When doing so you should have been prompted by the:

nxserver --useradd test
NX> 906 Setting password for user: test.
NX> 251 Password:
NX> 102 Confirm password:
NX> 110 Password for user 'test' has been added to the NX password DB.

And now, as long as EnablePasswordDB is set to 1, you need to provide this new password to connect.

There is a problem though, if you added that user before setting EnablePasswordDB to 1, there would have
been no new password prompt, and the user would not have its NoMachine password provided.
You would need to do the useraddd command again to fix it.

There is one exception to this, when using SSH connection protocol you still need to provide system password as per the SSH configuration, then after this you will be again prompted by the NoMachine password question.

So for now please try those things:

1. Remove the ‘#’ from server.cfg ‘#EnableUserDB 1’ line.

2. Run ‘sudo /usr/NX/bin/nxserver –useradd <username>’ again and see if you have password prompt, if yes, please
provide it and use that password to login. Be sure you are using NX protocol.

3. If still no use please run ‘sudo /usr/NX/bin/nxserver –passwd <username>’ and set new password again, just to rule
out there was no typos, and use that password to login.

4. If it still does not work, please set in server.cfg

EnableUserDB 0
EnablePasswordDB 0

And try to login using the system credentials.

5. If that attempt also fails, there may be more to this problem, and we would like to see the logs as there might me unexpected bug behind this.

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please enable the debug and then try to login again and send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

The logs you provided suggests there is something wrong with the IP address or port you are trying to connect to.

When you say “There are 2 IPs listed” do you mean the addresses provided by the player application from “My machines” view?

Since you are using vpn there is always a possibility that NoMachine did not list every network interface and the valid IP is simply not there. Could you ascertain which IP is proper for the target machine and use the “add new connection” in the player application to provide the valid address?

If the connection still does not work like that, please check if there is nothing blocking the 4000 port on the target machine. You can also try to change the protocol used during the connection from the NX to SSH (from connection details menu) this will also change port used to connect to
22 (if you are connecting to linux/osx) or 4022 (for connections to Windows).

Also on the target machine please check if the nxd process is running and also for any errors/warnings in the NoMachine logs. Most likely place would be nxd.log and nxserver.log.

/Mth

[Mth]

Hello

From the logs it seems that there is a problem with installation. We have:

/usr/NX/bin/nxnode.bin: symbol lookup error: /usr/NX/lib/libnxdiag.so: undefined symbol: deyaultPoi9terContSol

There are no nxinstall or nxupdate logs included, so I am not able to tell, but was it a clean installation? Maybe there was some directories left from previous one?

The log suggests some kind of modified, old or broken libraries present, so right now the only thing to do would be a clean installation.

If you have version free or evaluation, it is probably safe to ignore points 1, 5 and 6 of this instruction.
It is only relevant if you have received custom license files from us or using modified configuration files.

1. Backup all the modified files from /usr/nx/etc directory (important to keep .lic files if you are a customer
with custom license and .cfg or .db files when modified)
2. Uninstall NoMachine.
3. Remove /usr/NX, /etc/NX and /var/NX directories if they still exist.
4. Install NoMachine.
5. Restore backed up licenses as per https://www.nomachine.com/AR11O00942 article.
6. Restore backed up cfg and db files.

Please let us know if it helped, or if the issue persists after reinstall.

/Mth

 

[Mth]

Hello.

First to clarify, when referring to the ‘nxserver’ command, on Linux systems by default the full
path is either:

/etc/NX/nxserver

or

/usr/NX/bin/nxserver

Then to the problem itself. The popup window ‘A configuration error has been encountered. Please contact your administrator.’
right now it can only be displayed during starting of a session when the ‘.ICEauthority’ file for the user that is starting
session has wrong owner.

You can confirm that this is the problem by checking the ‘/usr/NX/var/log/nxserver.log’ file.
The warning too look for is:

WARNING! The /root/.ICEauthority file has wrong ownership.

If this is the case please make sure that the file noted in that warning has proper ownership set,
in this case it should be:

stat /root/.ICEauthority
File: '/root/.ICEauthority'
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)

If the access rights are wrong you can modify them by running:

# chown root:root /root/.ICEauthority
# chmod 0600 /root/.ICEauthority

If this still does not help, please share any warnings/errors from ‘/usr/NX/var/log/nxserver.log’ and
‘/usr/NX/var/log/nxerror.log’ files.

/Mth

[Mth]

Hello.

First lets rule out the easy stuff.

There could be two issues here:

1. When on “no sessions available” screen, please make sure the view is set to “All desktops”.

2. Please make sure the user you are connecting with is marked as an administrator for NoMachine.
On licenses other than Enterprise Desktop we have something called “restricted access” to physical desktop, and the user has to be specifically marked as administrator to have full access to Login Window and desktop sessions.

If the user account has already been used to access NoMachine, please use:

/etc/NX/nxserver --useredit username --administrator yes

if not, please use:

/etc/NX/nxserver --useradd username --administrator yes

And try to connect again.

If this does not help please gather logs for investigation.

As it is Catalina, please gather information from the MacOS system log, preferably by running:

# cat /var/log/system.log | grep -e nxserver -e nxnode -e nomachine >> system.debug

and

/usr/bin/log show --debug | grep -e nxserver -e nxnode -e nomachine >> log.debug

Also please collect NoMachine logs.

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please include the system.debug file and send them to forum[at]nomachine[dot]com using the title of
that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello.

First let me elaborate on the available options.

When you have a headless Linux machine and NoMachine free version installed
and want to have access to graphic environment there are two ways to do it:

1. You can start it yourself by running the Xserver (like Xvfb) then starting
the environment (like “/etc/gdm/Xsession gnome-session”) there. This method
is explained in the article https://www.nomachine.com/AR10K00710.

2. You can let the NoMachine start its own Xserver on demand or by default.
If there is no Xserver running on the machine and the server.cfg key
DefaultDesktopCommand is set properly, during the first connection
you will be prompted to create and connect to new desktop.

That said, there are a few things to consider.

1. The physical desktop itself has to be installed. So like in the example
you provided (etc/gdm/Xsession gnome-session) both the Xsession script
and gnome-session have to be present.

2. When dealing with physical sessions, after changes in system it is good
practice to restart the nxserver afterwards. NoMachine regularly checks the availability of Xservers but when no Xserver is found after a certain time, it checks at longer intervals.

# /etc/NX/nxserver --restart

3. When starting Xserver by hand (like Xvfb in the topic you provided) you
have to make sure to start it as standard user and avoid starting it as ‘root’.
That is unless you specifically want to do it, starting graphical environment
as root can be dangerous. Here it is important to use the same user as the one
you want to use to connect via NoMachine. When the users are different, please
make sure that when on “no available sessions” screen the view is set to “All desktops” instead of “My desktops”.

And additional article that may help: https://www.nomachine.com/AR07Q01037

If there is nothing that helps in your problem, we could deduce more from the
NoMachine logs.

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

After gathering logs, please send them to forum[at]nomachine[dot]com using the title
of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello.

I am terribly sorry, don’t know where the error came from, but of course this
is MacOS, so the path is not /usr/NX, but /etc/NX.

So the commands should be:

‘# /etc/NX/bin/nxserver –userlist’

‘# /etc/NX/bin/nxserver –useredit –administrator yes’

Sorry for causing confusion.

/Mth

[Mth]

Hello.

Thank you for reporting the issue.

The first question is, when there was only one user in the system, was the operating system configured to log in this user automaticly,
or did you had to log in manually?

Second, do you have free version of NoMachine installed on the MacOS? If not, there could be two issues: one, when on “no sessions available”
screen, so please make sure the view is set to “All desktops”. The second is what account you are using: please make sure the user you are connecting with is marked as an administrator for NoMachine:

# /usr/NX/bin/nxserver --userlist

If it is not, please set it by running:

# /usr/NX/bin/nxserver --useredit --administrator yes

And try to connect again.

With the easy stuff ruled out, please gather logs for investigation.

Gather information from the MacOS system log, preferably by running:

# cat /var/log/system.log | grep -e nxserver -e nxnode -e nomachine >> system.debug

Also please collect NoMachine logs.

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please include the system.debug file and send them to forum[at]nomachine[dot]com using the title of
that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

From the logs you supplied it seems that the nxnode process that is accessing the physical desktop is segfaulting during the attach
procedure. This is causing the player to disconnect and trying to reconnect again, which with nxnode dead is causing a misleading
error “104: Connection reset by peer.”.

The nxnode process is dying with signal 11, so there should be a trace in the system logs or, if you have core dumps configured
a core file for investigation.

We are trying to reproduce this issue, but we would be grateful for a backtrace from this core file.

Please refer to the article https://www.nomachine.com/AR09L00810 on how to proceed with core file.

/Mth

[Mth]

Hello

The nxserver does a bit of monitoring in the background, NoMachine processes graphic environment tracking, which is not
always readily available in the system.

The 100% cpu usage after connection is unacceptable and abnormal though (unless of course there is a lot of swapping going on).

Could you please gather some logs for us to check this issue?

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please enable them, restart the nxservice:

‘# /etc/NX/nxserver –restart’

and then connect to the machine.

Also please include the strace for this nxserver.bin process.

‘# strace -f -p <nxserver.bin PID> &> strace.log’

You can find the nxserver.bin PID in the top view. Please let this command run for a full cycle of 100% usage and then terminate it with ctrl-c.

After gathering logs, please send them to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello.

This doubling of processes is most likely caused by the NoMachine starting the virtual desktop because it cannot detect the physical
desktop and the server.cfg key CreateDisplay is set to 1.

To avoid NoMachine creating it on each startup you can edit

/usr/NX/etc/server.cfg

config file and set this key to 0 or comment it.

This key may be set to 1 because when you first connected, NoMachine had no physical session detected, asked to create “Display on demand” (which is simple virtual session). When you select yes, there is a checkbox to select, which will make NoMachine to start this session automatically on startup.

Setting it to 0 will make it stop, but it does not solve the issue that you have running physical desktop and NoMachine did not detect it.

If this key is set to 0 and after doing

# /etc/NX/nxserver –restart

you would not get NX> 161 Enabled service: nxnode. and you cannot access your desktop, we would require logs
to investigate this further.

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

After gathering logs, please send them to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

The good news is we were able to identify the problem, and the fix
is under way. The bad news is that we cannot provide a straightforward
workaround.

The problem is happening because of the strange dbus service behavior.
By the default dbus-daemon –session should be ran by the systemd
whenever the user is logged. Here it does not happen and instead it
is invoked during the start of the graphic environment by the gdm-x-session
process.

So we have three important processes running as gdm-x-session children:
Xorg, dbus-daemon –session and gnome-session-binary. Unfortunately
the dbus-daemon started like this lacks some of expected environment
variables, and the NoMachine fails the detection badly.

Please check if there is anything wrong with the dbus service for the user e.g. by
running

‘systemctl status dbus.service’

or checking if the file /usr/lib/systemd/user/dbus.service is present and viable.

If there is nothing wrong there, or it is not a result of an accident and this
behavior is intended, we may be able to provide with patched packages.

/Mth

[Author]

Posts