January 25, 2021 at 09:43 #31515
When trying to login to a Windows 10 system (tried two different systems), and the user used to connect is already logged in, NoMachine fails with error message:
The session negotiation failed. Error: Last operation failed
When I logout the user on the Windows 10 system, and then try to connect, it works. This is EXTREMELY annoying, in particular because when you disconnect the session like ALT-CTRL-0 -> Connection -> Disconnect, the user will stay logged in, but you won’t be able to connect back in again. Relevant messages in connection log:
NX> 105 Listsession –status=”disconnected\054connected” –type=”all” –shadowable=”yes”
NX> 127 Session list of user ‘rubin’:
Display Type Session ID Services Depth Screensize Status Session name Username Platform Users Create Node
——- —————- ——————————– ——— —– ———- ——— ————————– ——– ——– —– ———- ————–
1001 physical-desktop C721E16F3A9DF06BD39466E3F159D929 –D–PSAD N/A N/A Connected Local display on localhost rubin windows 0 1611351614 localhost:4000
NX> 147 Server capacity: reached for user: rubin
NX> 105 Setsession –id=”C721E16F3A9DF06BD39466E3F159D929″
NX> 754 Selected node: localhost:4000
NX> 105 Resourcelist –node=”localhost\0724000″
Note that this behaviour is markedly different when targeting macOS: There, when I try to connect to macOS system and the user is already logged in, it simply connects and takes over the desktop.
Is this behavior a bug or an intentional limitation of the free version?
NoMachine Client and Server versions: 7.0.211
Rubin.January 25, 2021 at 15:47 #31553BritgirlKeymaster
It’s certainly not a limitation and I am not aware of any bug that would cause different behaviour.
The free version counts connections to the remote desktop. If the a user connects remotely to the desktop, this counts as one connection. If the same user then connects (same username) from another device, the connection is migrated to the second device. This is the expected behaviour.
Can you submit the full set of logs from the Windows server computer? You can extract them by following the instructions here:. https://www.nomachine.com/it/DT11R00182. Then send them by email to forum[at]nomachine[dot]com making sure to put the title of the topic as the subject. Thanks.January 25, 2021 at 16:38 #31554January 27, 2021 at 09:58 #31586GegaParticipant
It seems like nxnode terminates unexpectedly on Windows when SSH_AUTH_SOCK environment is set, we fail to create symlink and fail, this is the issue.
We will create a trouble report for it and we will link it in this thread.
However, SSH_AUTH_SOCK environment variable is used during ssh forwarding, but in your case you authenticate using NX protocol and password authentication, so it’s not quite clear where the SSH_AUTH_SOCK environment comes from.
It looks like SSH_AUTH_SOCK isn’t in the environment of nxnode process when the user is logged out and everything works fine, but the problem appears when ruben is logged in and we create nxnode process run as user “ruben” which for some reason has SSH_AUTH_SOCK in the environment. Could it be that processes run as user “ruben”, has by default SSH_AUTH_SOCK in the environment?
Unsetting SSH_AUTH_SOCK could be a workaround to avoid this issue.January 27, 2021 at 13:17 #31604
SSH_AUTH_SOCK is set for user rubin when logged in, for sure, and used by my various SSH tools (ssh/gpg agent, ssh clients, etc). I would expect NoMachine to ignore SSH_AUTH_SOCK when ssh is not used to connect; is this a bug in NoMachine? unsetting SSH_AUTH_SOCK is not really an option (all my other ssh-based tools would stop working).February 11, 2021 at 09:32 #31914
Any update on that trouble report and/or in which version of NoMachine this will be fixed?
RubinFebruary 11, 2021 at 13:28 #31923
You must be logged in to reply to this topic.