Forum Replies Created
Please take a look at https://www.nomachine.com/AR11L00827
It looks like there something other then NX daemon listening on your server side.
Please verify that port 3389 is used by nxd process.
Please set AcceptedAuthenticationMethods key in server.cfg.
This key was made available in latest update of NoMachine 5.
# Specify how clients will have to authenticate to the server, by
# default all the available methods are supported. This corresponds
# to value all. To specify a subset of methods use a comma-separated
# Supported methods for connections by NX protocol are:
# NX-password : Password authentication.
# NX-private-key: Key-based authentication.
# NX-kerberos : Kerberos ticket-based authentication.
# Supported methods for connections by SSH protocol are:
# SSH-system : All methods supported for the system login.
# SSH authentication methods for the system login
# have to be set on the system for example in the
# PAM configuration.
# SSH-nomachine : Server-based DSA key and password authentication.
# For example:
# AcceptedAuthenticationMethods NX-private-key,SSH-system
# This key has to be used in conjunction with ClientConnectionMethod.
# See also the EnableNXClientAuthentication key for enabling SSL
# SSL client authentication for connections by NX protocol.
We are working on feature that will allow such control, it should be released in one of the upcoming updates to 5.0. Right now this can be archived by using third party tools, for example firewall. Moving SSH access to NoMachine from default port 22 to custom one may help.
Do you have physical access to that machine to performa a manual restart of NoMachine server or reboot of machine?
Issue is under investigation.
If any from users who experience it is willing to help please submit logs to forum[at]nomachine[dot]com
As far as I understand you have two Windows machines, Windows 7 and Windows 10. NoMachine works correctly on 10 but not on 7. How Linux, mentioned by you, is involved in that scenario?
To help us investigate this problem please collect logs on affected machine and submit to forum[at]nomachine[dot]com.
NoMachine authentication process authorise user to access desktop currently running on computer, no matter if it’s a user session or login screen.
We don’t interact with a desktop itself and it’s up to a user to perform system authentication if a login screen is displayed.
Are you using Raspbian on your RPI2 device?
If yes then please download a version for ARMv6 available on our page.
A version you used is for Ubuntu/Debian build for ARMv7.
Port 20084 on your local router was configured automatically by NoMachine or you did it by hand?
NoMachine doesn’t provide packages that can work natively on ChromeOS.
It’s possible to run NoMachine for Linux after installing Linux on Chromebook as a second system.
It was verified to work on:
Samsung Chromebook 303c (ARM)
Acer Chromebook c710-2856
Asus Chromebox CN60
Alternatively you can use Web Player which is part of Cloud Server.
Please send logs to forum[at]nomachine[dot]com.
For some reasons files ware not attached to your post.
Are you using LDAP?
How your installation is differ from?
Commands are not executed with help of sudo.
You can try to test them manually with:
$ sudo su - nx -s /bin/bash $ /bin/ps awwxo ppid,pid,sid,comm,args $ /bin/netstat -ln --protocol=unixJuly 17, 2015 at 10:32 in reply to: Custom software/script to give instructions to NoMachine (Client) #7741
There is no API or any other interface in NoMachine that you can use to control Player.
However you can use third party automatisation solutions like for example Sikuli – http://www.sikuli.org.
It’s a tool used by us and it works great.
It’s not only nxd that fails with signal 13. Even system tools like ‘netstat’, ‘ps’, ‘ck-list-sessions’ are failing in the same way.
Do you have AppArmor or SELinux enabled?
Can you check system logs to see why execution of all these commands is blocked?