Mth

[Mth]

Hello

From the logs you provided the reason seems to be here:

2020-03-10 13:03:06 012.355  8568 NXSERVER WARNING! Process 'c:\apps\nomachine\\bin\\nxexec --server --upnpstatus' with pid '9152/812' finished with exit code 1 after 0,015 seconds.

9152 1328 13:03:06 012 nxexecExecServer: ERROR! Only nxnode or nxserver can run --server command.
9152 1328 13:03:06 012 nxexecExecServer: ERROR! Cannot execute nxserver process.
Error code is : 0.^M
9152 1328 13:03:06 012 main: ERROR! Error: Server exec failed.

This is a bit of a puzzler, the path c:\apps\nomachine\\bin\\nxexec clearly exist, it is
clearly executed by nxserver, but the nxecec cannot recognize it.

The problem could be a result of bad installation, did you choose c:\apps\nomachine during the installation, or it was copied afterwards?

There is also a file ‘c:\ProgramData\NoMachine\nxserver\localhost\server.cfg’,
could you confirm that in this file a key “ServerRoot” is set up to point to the installation directory?

/Mth

[Mth]

Hello

The problem indeed is that the nxserver cannot open any socket to listen on. It should not be the fault on the NoMachine side,
at least not in normal circumstances. You should be able to find more clues in nxerror.log file – if the system reports a reason,
or in the operating system logs.

Please check if there is any clue to this within the Ubuntu logs, or the parent system logs – most probably it is because of how the chrooted system is set up, the parent OS is blocking any attempts to open a socket.

If there is nothing wrong in the system logs, please elaborate more about the system setup and how did you exactly set up the chroot environment.

We may need to reproduce the problem to handle it.

/Mth

[Mth]

Hello.

The logs shows that every instance of nxexec process is being blocked.
Most commonly there are problems with apparmor blocking the docker container.
We have a document on this topic:

https://www.nomachine.com/DT10O00161

Please check the troubleshooting part of that document.

There also can be a problem with the privileges on the container, sometimes
it is also required to add

--privileged

parameter to docker run command.

If the article does not help you, please check if there is anything in the system logs
of the parent operating system that could be relevant to starting any nx processes,
any access blocking, termination etc. Also please share the Dockerfile and the command
you use to start the container for us to debug.

/Mth

[Mth]

Hello

Sorry for the confusion, the proper command would be:

sudo /etc/NX/nxserver --debug --collect

This command should point you to the generated archive, like:

NX> 900 Archive is: /usr/NX/var/log/archives/NoMachine-log-2020.02.12-10.28.14.zip

Please send this archive and the ‘su’ file to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

There are a few things to check:

1. In /usr/NX/etc/server.cfg what are the values of keys EnableUserDB and EnablePasswordDB?
Are they commented?

If they are commented or set to 0 it means the NoMachine will use
system authorization to authenticate users. Skip point 2 and go to the point 3.

2. If both this keys are set to 1, NoMachine is using the internal password database
to authenticate users. please use command

# /etc/NX/nxserver --passwd <username>

to set new password and try again.

3. To rule out the simplest mistake, please check if you can use the username/password to login into system.

4. To check for NoMachine authorization problems please run

/usr/NX/bin/nxexec --auth

and use the Username and password used for failed connection. Please provide us
with output.

5. Please check the NoMachine log files for errors/warnings connected with the user login
Files are /usr/NX/var/log/nxserver.log and /usr/NX/var/log/nxerror.log.

6. Please check the system log file – for ubuntu it should be /var/log/auth.log – for any errors connected with failed login.

/Mth

[Mth]

Hello.

Unfortunately NoMachine logs cannot be read by a normal user, even if the directory
rights are proper. You will need sudoer or root account to access and copy them.
You can also use the command

etc/NX/nxserver --debug --collect

to make NoMachine collect and package them itself, but this command also requires
the sudo/root access.

As for the pam.d directory, it is not NoMachine configuration, but rather system
configuration, so it will not be in ‘/usr/NX’, but in system directory ‘/etc’.

/Mth

[Mth]

Hello.

For now it seems the problem is not with Xvfb, but with the NoMachine processes and docker itself.
It seems we want to make this display visible, but every process dies with exit code 1.

First we need to check if the container is properly run. We have a document on this topic:

https://www.nomachine.com/DT10O00161

Most commonly there are problems with apparmor blocking the docker container from running
processes using nxexec. Please check the troubleshooting part of that document.

There also can be a problem with the privileges on the container, I found that on one specific machine
with Mint I need to add –privileged parameter to docker run command.

If the article does not help you, please check if there is anything in the system logs that could
be relevant to starting any nx processes (any access blocking, termination etc.). Also please share
the Dockerfile and the command you use to start the container. With this it should be easy for us
to reproduce the problem to find a solution.

/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

[Author]

Posts