Server capacity: reached for user, when user is logged on at physical desktop

Forum / NoMachine for Windows / Server capacity: reached for user, when user is logged on at physical desktop

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #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

    Kind regards,




    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:. Then send them by email to forum[at]nomachine[dot]com making sure to put the title of the topic as the subject. Thanks.



    Client and server logs for a session. Client could not connect, message from server is: 147 Server capacity: reached for user: rubin


    Hello rubin,

    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.


    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).


    Any update on that trouble report and/or in which version of NoMachine this will be fixed?


    Kind regards,




    We’ve opened trouble report for this case: TR02S10068


    The TR associated with this forum post was closed in the software release 7.2.3: Error ‘The session negotiation failed’ occurs when a user is already logged on at the physical desktop

    NoMachiners, please update 🙂

Viewing 8 posts - 1 through 8 (of 8 total)

This topic was marked as solved, you can't post.