Forum Replies Created
We provided you with patched version fixing issue with unavailable descriptor, described in this thread: https://www.nomachine.com/forums/topic/error-descriptor-fd_____-not-available
In logs you recently sent we found another issue. It’s not possible to obtain home directory for ‘nx’ user. In past such problem occurred when Windows hosts were part of Active Directory and NoMachine was installed on Domain Controlled (Windows Server). Is this a case in your setup? Can you uninstall NoMachine on Domain Controller and reinstall NoMachine on hosts on which you experience problems?
We can try to extract more information from memory dumps generated during lsass.exe crash. You should be able to find them in ‘C:/Windows/Minidump/‘. We’re interested in recent *dmp file.
Please contact us via email at forums[at]nomachine[dot]com on details about uploading memory dump. Include link to forum thread in subject.
In the meantime, you can uninstall nxlsa module, if you don’t need server’s functionalities.
This command needs to be executed with Administrator’s rights:
\bin\nxservice64.exe –uninstall nxlsa
Problems with lsass should be gone after reboot.
Please gather client side logs after failed authentication attempt, following these instructions:
It would also be helpful to see the content of ‘/etc/pam.d’ directory.
Send logs and tar archive of ‘/etc/pam.d’ to forums[at]nomachine[dot]com.
Please, check thread:
and verify if you’re experiencing:
Please make sure that you started ProcessExplorer as Administrator, when it’s launched without rights elevation it doesn’t correctly report protection mode.
In case you rule out protection level as potential source of problems, send us server-side logs gathered according to these instructions:
Send them to forum[at]nomachine[dot]com
We created trouble report for your issue:
We’re intensively working on solution, you can follow the state of TR.
What kind of antimalware software do you use, if any? We’re aware of problems with NoMachine when lsass.exe system service runs in protected mode which is often enabled by installation of antimalware applications.
To verify that this happens in your case:
1. Download and install Process Explorer using this link:
2. Start Process Explorer as Administrator.
3. Double click on lsass.exe process anc check the value of ‘Protected’March 2, 2017 at 09:06 in reply to: Authentication Failed: ERROR! kDestroy does not exist #13953
We need logs from your NoMachine server machine. Please, use these instructions:
https://www.nomachine.com/DT07M00098, and send them to forum[at]nomachine[dot]com.
Excerpts which were provided by you suggest that NoMachine fails to start nxnode process, because it can’t validate user. If you use some specific technology for user management, like LDAP or Active Directory, it’s possible that you need to adjust ‘/etc/nsswitch.conf’ file to include alternative sources of user information.
As you noted, authentication succeeds, login fails at account validation. If you are authenticating against Active Directory it’s worth checking security settings on Domain Controller. Perhaps user or one of groups to which user belongs is denied logon to host.
You can also try to replace content of /etc/pam.d/nx with content of /etc/pam.d/sshd. It appears to me that sshd PAM configuration might not include pam_sss in account stack. If this is the case, be aware that some account management functionalities, like password reset, won’t be present any more.January 11, 2017 at 12:04 in reply to: Where do I set the path to nxclient working directory? #13491
Your issue could be solved in two ways:
1. Allowing access of nxnode process to user’s home directory.
2. Using alternative location for ‘.nx’ directory.
We need to establish why nxnode is denied access. Are you using AFS, NFS or any other specific file system? You stated that directory is not accessible by root. This shouldn’t matter because nxnode process runs on behalf of connected user. The only exception is when session is started for root himself. In such case nxnode runs impersonating nx user. If you use AFS perhaps you experience this bug:
Check if updating NoMachine helps.
We’ve got feature allowing to configure ‘.nx’ directory location:
Note: In article USER_NX_DIRECTORY_PATH key is mentioned, the proper key name is UserNXDirectoryPath.
We understood the problem and are working on proper solution. Thank you for cooperation. Fix will be officially released before Christmas. Perhaps you’re interested in trying out test packages in the meantime?
It seems that nxservice64.exe process might be missing some privileges.
To verify this:
1. Download and install Process Explorer from:
2. Start Process Explorer as Administrator.
3. Right-click on nxservice64.exe process, select Properties, and go to Security tab.
4. In the lower pane you should now see privileges held by process.
Please, provide us the list of privileges with Flags Disabled.
Number of open handles of lsass.exe process which you attached to previous reply is pretty big. This may be due to handles leak, which might be caused by some of custom authentication packages installed on your host. Is there anything specific about your setup which could affect authentication process and behavior of lsass.exe process? Can you check the number of open handles of lsass.exe shortly after OS reboot? Does this number grow over time? If so, could you estimate the rate of growth in time?
We experienced similar behaviour when AppArmor blocked access to ‘/proc/‘ directory of container. Possible solution is described in section TROUBLESHOOTING of the following article: https://www.nomachine.com/DT08M00100&dn=docker.