Waiting for the desktop user to authorize your connection

Forums / NoMachine for Linux / Waiting for the desktop user to authorize your connection

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #27769
    rpr
    Participant

    On Ubuntu 20.04 LTS AMD64 (running GNOME desktop) I fresh installed NoMachine for Linux 6.10.12.

    When I connect to the machine with NoMachine Enterprise Client 6.10.12 for Windows, it says: Waiting for the desktop user to authorize your connection.

    On some earlier versions of NoMachine for Linux it did not require the authorization of the connection in default configuration.

    The problem has been solved by setting the following option in /usr/NX/etc/server.cfg
    PhysicalDesktopAuthorization 0
    and restarting the nxserver.

    Can anyone comment since when the behavior of NoMachine changed regarding the desktop authorization?

    –rpr.

    #27783
    Mth
    Contributor

    Hello.

    Assuming that you are using the free version of NoMachine, not trial, just clean free,
    by default the connection to physical desktop should be working like this:

    1. When there is Login Window, you can connect with any user without prompt.

    2. When there is user desktop logged, you can attach as the same user without prompt.
    If you enter different credentials in NoMachine player, you are not desktop owner
    and there could be a potential security risk involved, so you can only access when
    someone accepts the connection.

    The PhysicalDesktopAuthorization key should be a voluntary administrator decision
    to let other accounts to access desktop, but only if different account is logged
    to the desktop than the one used in NoMachine player.

    There was not any change to this behaviour in a long time, so if it is not a case
    of different accounts it could always be some bug with detecting session owner.

    /Mth

    #27851
    rpr
    Participant

    I’ve done some more testing on the Ubuntu 20.04 machine which has only two ordinary users (with UID >= 1000). It is running the free version of NoMachine for Linux 6.10.12.

    After rebooting the machine I tried to connect to it with NoMachine Enterprise Client 6.10.12. The login to the NX server was successful but then the client displayed “Waiting for the desktop user to authorize your connection” although there was no desktop user logged in. After a few seconds I closed the client.

    Here are the NX log records I found about the session (after logged in via SSH):

    /usr/NX/var/log/nxserver.log
    2020-05-29 16:38:32 483.721 799 NXSERVER Starting LS 6.10.12 and services.
    2020-05-29 16:38:32 570.233 799 NXSERVER System information: Ubuntu 20.04 LTS, standalone.
    2020-05-29 16:40:41 833.970 1674 NXSERVER User ‘rpr’ logged in from ‘192.168.33.30’ using authentication method NX-password.
    2020-05-29 16:40:49 689.909 1674 NXSERVER User ‘rpr’ from ‘192.168.33.30’ logged out.

    /usr/NX/var/log/nxerror.log
    799 1121 16:38:39 608.816 ServerNetworkInfoHandler: WARNING! Obtaining network data failed.
    Info: Handler started with pid 1674 on Fri May 29 16:40:35 2020.
    Info: Handling connection from 192.168.33.30 port 54246 on Fri May 29 16:40:35 2020.
    Info: Connection from 192.168.33.30 port 54246 closed on Fri May 29 16:40:49 2020.
    Info: Handler with pid 1674 terminated on Fri May 29 16:40:49 2020.

    /usr/NX/var/log/nxd.log
    Info: Server started with pid 1110 on Fri May 29 16:38:32 2020.
    Info: Listening for connections on any interface on port 4000.
    Info: Accepting connections from any host with encryption enabled.
    Info: Connection from 192.168.33.30 port 54246 accepted on Fri May 29 16:40:34 2020.
    Info: Connection from 192.168.33.30 port 54246 process 1674 started on Fri May 29 16:40:34 2020.
    Info: Connection from 192.168.33.30 port 54246 process 1674 closed on Fri May 29 16:40:49 2020.

    /usr/NX/var/log/node/C-mypc-1001-5A2D779FBAC40F198A4A621338E99811/options
    nx/nx,slave=1,id=mypc-1001-5A2D779FBAC40F198A4A621338E99811,cookie=36E1262303CC4A808E619685898BA889,audioin=5:5:vorbis:socket-/run/nxdevice/D-1001-5A2D779FBAC40F198A4A621338E99811/audio/native.socket:1,voiceout=5:5:speex:socket-/run/nxdevice/D-1001-5A2D779FBAC40F198A4A621338E99811/audio/native.socket:1,cpus=2,hwenc=1,encmode=auto,monitor=9,threads=auto,priority=realtime,dxgrab=0,legacykb=0,shadow=:1024:1001

    /usr/NX/var/log/node/C-mypc-1001-5A2D779FBAC40F198A4A621338E99811/session

    NXAGENT – Version 6.10.12

    Copyright (C) 2001, 2019 NoMachine.
    See http://www.nomachine.com/ for more information.

    Session: Starting session at Fri May 29 16:39:06 2020.
    Info: Agent running with pid 1378.
    Info: Slave server running with pid 1400.
    Info: Listening to slave connections on port 12001.
    Info: Display running with pid 1401.
    Info: Audio server started with pid 1415.
    Info: Audio client started with pid 1416.
    Info: Display server started with pid 1417.
    Session: Session started at Fri May 29 16:39:07 2020.

    In the logs I don’t see any obvious problem.

    The same thing happens if I use the other user’s credentials for NX login in the client.

    As I wrote, the only solution to the problem is to set
    PhysicalDesktopAuthorization 0
    in /usr/NX/etc/server.cfg

    Any comments?

    #28394
    Mth
    Contributor

    Hello.

    As I wrote before, as there was not enough information to make any reasonable guess, this is how this key is supposed to work.

    With what you provided it is clear that there is something wrong. For one you should never be asked for “desktop user to authorize your connection” on login window.

    As for the logs, I doubt there will be anything important on the default debug level, as when the NoMachine detects the physical session, unless some error happens there is no reason (yet) to disbelieve what was detected.

    So we would require some additional information to help debug this problem. I see the operating system in logs (Ubuntu 20.04 LTS), but which desktop environment and desktop manager are being used? Is it a physical machine or a virtual? Is Wayland being used for login window or/and desktop? If it is a physical machine is there a monitor (or multiple) connected or is it a headless system?

    And as I mentioned, we need to increase the debug level to see what is happening in more detail. If you are willing to help us further please refer to an article on how to enable debug:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    Enable debug on the server machine and then do:

    sudo /etc/NX/nxserver --restart

    Then please gather logs either manually or by executing:

    sudo /etc/NX/nxserver --debug --collect

    Please send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the mail’s subject.

    /Mth

    #28420
    rpr
    Participant

    Hello, Mth!

    Here are the information about the machine where the issue occurs:

    Physical machine: HP dc5850sM with AMD Athlon X2 5200B, 4 GiB DDR2, on-board ATI Radeon 3100
    OS: Ubuntu 20.04 LTS
    Architecture: AMD64
    Desktop environment: GNOME (default for Ubuntu 20.04)
    NoMachine for Linux 6.11.2 (free version)

    Client: NoMachine Enterprise Client 6.11.2 on MS Windows 10 19.03 x64

    I’ve just sent the debug logs.

    — rpr.

    #28440
    rpr
    Participant

    I forgot to mention two things:

    • Wayland is not used for the desktop on that machine:
      $ echo $XDG_SESSION_TYPE
      x11
    • The machine does not have a monitor connected.

    — rpr.

    #28467
    Mth
    Contributor

    Hello

    Thank you for the logs and information.

    It seems that on Login Window you still have the Wayland enabled, and
    for unknown reasons we are detecting it as a desktop, so this will need a fix
    from our side.

    For now you can try disabling the Wayland from the login window too,
    desktop and login window has different configurations.

    /Mth

    #28496
    rpr
    Participant

    I followed your advice and set the following option in /etc/gdm3/custom.conf:

    # Uncomment the line below to force the login screen to use Xorg
    WaylandEnable=false

    After system restart I can confirm that this change solved the issue.

    — rpr.

    #28919
    frfu8670
    Participant

    Uncommenting WaylandEnable=false on /etc/gdm3/custom.conf did the trick for me too

    Also on Ubuntu 20.04 and was pulling my hair out trying to figure out why. Thank you rpr and Mth for all the investigation carried out. Much appreciated.

    I created an account just to say this haha!

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

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