Forum Replies Created
-
Posts
-
Hi,
It looks like KDE is not starting properly. It’s hard to say only from client side logs.
You should check possible error messages in the user’s home directory ‘.xsession-errors’ file and system logs. Also ‘clients’ file in/usr/NX/var/log/node/F-C-<session ID>/could say what is going on with this application.
You could also try to startcustom session: console in virtual desktopand run KDE start command manually to check exact error message.Hello hule,
Please check permissions to /tmp directory:$ LANG=ENG ls -la / | grep tmp drwxrwxrwt 16 root root 4096 Mar 14 10:56 tmpWe are using ‘/tmp’ directory to exchange descriptors, it should be accessible by every user.
Hello slogger123,
The cluster (shared) IP has to be fixed, this is the main part of the cluster. If the active server fails then the other one is starting and creating the same IP so users can reconnect.The shared interface needs to be created on the common subnet for both cluster machines. Also, cluster machines need to be able to communicate
with each other. It could be the same subnet as above or the other one.If this is required:
the active server in production datacentre and the standby in the DR centre
then I can suggest creating separate nodes for both cluster host. First, you need to create cluster after that I add nodes separately for both cluster machines. You have to remember to not execute ‘–clusterupdate’ after that as this command will synchronize node database, and you want to keep it separate.
Hello slogger123,
That’s an interesting scenario.The NoMachine Cluster was designed to solve a single point access problem for a multi-node environment. The cluster is providing a back-up server to take over traffic and reconnect users to their’s session on the remote nodes in case of disaster event on the current access point.
A good practice is to keep cluster servers in the one subnetwork, so they can establish between each other with is currently active: providing access to all nodes and with one is only monitoring first server status.
With have that on mind you can design your cluster in every way you want 😉
Hi 7777777,
We cannot reproduce the problem with our laboratory.Please provide as much detail as possible about the environment you are using to virtualize the machine and we will prepare ‘sandbox environment’ were you could reproduce the issue.
In particular we are inserting in the virtualization infrastructure (KVM, VMware, VirtualBox, etc) and the machine parameters (like CPUs, RAM and any option that could be important).
Please also provide exact NoMachine package version that you are using.
Also I am still not sure if you are accessing physical desktop on virtual machine or you are creating new virtual session.
Hi 7777777,
Logs in nxnodes working directories do not contain any particularity error that could point the problem.
We need debug logs. Please enable debug level log in server.cfg and node.cfg files on the server.
Please also set SessionLogClean on 0. Then restart NoMachine and after issue occurs upload full var/log
directory to forum[at]nomachine[dot]com.What Linux version are you using in the virtual machine?
Hi 7777777,
It looks we have some problems with establishing the connection to nxagent.
Do you accessing physical desktop on this machine or is it a headless Linux?
We would need ‘node’ directory to analyze nxnode working directories.
You could attach it here or send to forum[at]nomachine[dot]com.
Please reference your forum topic when sending the logs.Hello 7777777,
It looks like nxserver processes that should handle the connection were killed:
Warning: Handler process 869396 died with signal 9, SIGKILL.
Warning: Handler process 869916 died with signal 9, SIGKILL.
Warning: Handler process 870367 died with signal 9, SIGKILL.We need nxserver.log to check the possible reason if possible with debug enabled.
Please follow the instructions here:
https://www.nomachine.com/AR07K00677Please also check system logs for possible issues with those processes.
Hello ascwonter,
NoMachine automatically configures the most common firewalls so users do not have to do it manually. You can find more details about this feature in server.cfg key description.#
# Enable the server to automatically configure the firewall for all
# the configured services. On platforms that don’t support adding
# the specific executables to a white list, the needed ports are
# added at server startup and removed at server shutdown, or when,
# at run-time, a new port is needed. The default value is 1.
#
# 1: Enabled. NoMachine opens the required ports in the firewall.
#
# 0: Disabled. Firewall must be configured manually. By default
# the required ports are TCP ports 4000 for NX, 4080 and 4443
# for HTTP and UDP ports in the range 4011-4999 range.
#
#EnableFirewallConfiguration 1Hello grgi,
The Wi-Fi network problems could explain issues with establish connection to the session.
There are errors suggesting issues with the connection:
ProxySession/ProxySession: ERROR! Session failure in stage ‘StageWaitingProxyVersion’.
ProxySession/ProxySession: ERROR! Shutting down with cleanup timeout expired.We need logs from server and client sides to have a full picture and confirm that.
Please follow the instructions here:
How to gather debug logs
Send them to forum[at]nomachine[dot]com making sure to reference your topic.Please also consider update server to NoMachine v6.
Hello grgi,
Unfortunately ‘nxserver.log’ file is corrupted.But in session logs in node directory we have a lot of errors like:
Error: Connection to ‘localhost:25001’ proto ‘TCP’ failed.
Error: Error 113 ‘No route to host’.Please check if ‘localhost’ is properly added to /etc/hosts file on the server.
There should be entries like:
127.0.0.1 localhost
127.0.1.1 ‘your server hostname’Something is blocking connections to nxserver –daemon process.
In nxserver.logs we have a lot of warnings like:
2018-05-09 17:58:30 999.458 3016 NXNODE WARNING! libnxh::NXConnectLocal cannot connect to localhost:23568: Connection refused from NXLocalSession::registerIntoServer.
nxserver –daemon process is listening on 23568 but connections are blocked.
Please try to check system logs for possible reason.
Restarting NoMachine service might help, but please use nxserver –restart command.
Hello andrewa,
NoMachine require keys to be in OpenSSH format. PuTTYgen.exe could be indeed hard to use to generate a proper pare of keys. I am glad that you worked this out! We don’t support additional option keys in authorized.crt. The key must be in format: key-type data comment.Hello bLuNt_wAcO,
We need more information to investigate further.Please gather logs from client side (Mac OS X):
https://www.nomachine.com/DT04M00076#6
and on the server side (Windows):
https://www.nomachine.com/DT04M00076#3Send them to forum[at]nomachine[dot]com making sure to reference the topic in your email.
Did you follow instructions in the article to set up key based authentication with NX protocol?
https://www.nomachine.com/AR02L00785Especially did you add key properly to the file:
<user's home>/.nx/config/authorized.crt
on Windows server properly.What’s your NoMachine version on server?
Are you using domain user to login to Windows (in both cases)?
Hello asens,
Thank you for taking the time to report this. It looks like some
permissions of NoMachine installation was broken. About two hours after
installation we can find errors like:
Subscription file/usr/NX/etc/server.lichas wrong permissions. Correct permissions are 0400.
To investigate further please provide output of commands:ls -l /usr/NX/ ls -l /usr/NX/etc/ ls -l /usr/NX/scripts/ ls -l /usr/NX/bin/and ‘.nx’ directory from home directory:
tar -cvp --exclude 'cache*' --exclude 'images' --exclude 'recording' -f - <path to user's home>/.nx | gzip -c >nxdir.tar.gzI am not sure what could cause this problem, but I would suggest
re-installation to fix problem with broken file rights.