Ubuntu 23.10 error 54: Connection reset by peer

Forum / NoMachine for Linux / Ubuntu 23.10 error 54: Connection reset by peer

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #45827

    Hi there, I have tried installing NoMachine on a fresh Ubuntu 23.10 and connecting to it from a Mac. I keep getting “Error is 54: Connection reset by peer”. I understand that technically it is not supported, but it was installed without error and everything seems to work until ProxySession errors out. I wonder if this is due to an incompatible version or bug/configuration problem. When I look into the session log, I see the following lines:

    Session: Starting session at Sat Oct 28 18:06:25 2023.
    35604 775 2023-10-28 18:06:25 122.125 Connection: Stop reading after switching the connection.
    The XKEYBOARD keymap compiler (nxkb) reports:
    Warning:          Unsupported high keycode 372 for name <I372> ignored
    X11 cannot support keycodes above 255.
    This warning only shows for the first high keycode.
    Errors from nxkb are not fatal to the X server
    35604 61207 2023-10-28 18:06:40 942.773 ProxySession/ProxySession: ERROR! Session failure in stage 'StageWaitingProxyVersion'.
    Error: Session negotiation failure.
    35604 61207 2023-10-28 18:06:40 942.835 ProxySession/ProxySession: ERROR! We possibly provided a wrong version
    35604 61207 2023-10-28 18:06:40 942.846 ProxySession/ProxySession: ERROR! or an invalid session authentication cookie.
    Error: Connection closed by the remote peer.


    In case it may help, here are some more details of the configuration:

    – Terminal: NoMachine for Mac free v 8.9.1_1, Mac OS 10.13.6

    – Remote (local network): NoMachine for Linux (deb) 8.9.1_1, Ubuntu 23.10, Gnome 45
    – Whether the problem arises connecting to a physical or a virtual display. Not sure about this: I have set Linux up with a display connected, but when trying to establish NoMachine connexion, the display is not attached (I switch it over to terminal).


    I have the same problem to a headless RPi4. Currently, I stop the display_manager and restart nxserver to fix this – it forces NoMachine to create it’s own display.

    It’s something to do with not being able to start a window session but this is the first time with the latest Debian bookworm version I have had this issue – I access several other pre-bookworm machines with no problems.


    sk.bsd, take a look at this Trouble Report which we opened for a similar issue to the one you are describing


    As a temporary workaround, disable Wayland.

    embee999, your issue is also known https://kb.nomachine.com/TR10U11031. There is a workaround in the TR.


    Thank you for your responses. I ran into this issue within 2 minutes of trying to set up a remote desktop. Certainly, I must be far from alone in this.

    I found that [removed] has no problem with Wayland without a monitor. Everything works, but it is quite slow and uses a lot of resources on the remote machine. I am not willing to disable Wayland just for this, so I will try other options like [removed], instead. I will report on the results here.


    Hi Forum, I have installed [removed] on my Ubuntu machine and a client on my Mac. I have no experience with NoMachine so far, but [removed] works way, way better than [removed]. There is no problem with switching the monitor to a different computer. Therefore, I can do just what I wanted, i.e. connect and disconnect a monitor without any trouble with remote connexion. It would probably not be a good idea to watch movies on your remote desktop (although possible), but everything else is pleasantly smooth. The LAN traffic is from 500 kb/s to maybe 1.5 Mb/s depending on what’s going on on the screen. The only problem now is that I cannot get sound from apps like FireFox. The system sounds work fine.

    One caveat: you cannot be logged on as the same user locally and through [removed] (I think this is the same with [removed] ). If you try a remote session while logged on locally on your remote machine, you will get an empty screen. This is a bummer because there is no explanation or warning anywhere.

    Hopefully, NoMachine will get this sorted out, too. I consider this an absolutely basic and indispensable functionality.


    ” NoMachine will get this sorted out, too. I consider this an absolutely basic and indispensable functionality.”

    So do we 🙂 you can keep tabs on the bug report using that link I posted. If you’re wondering why there is [removed] in your replies, it’s because a policy of the forum (which you agreed to when registering) is that we don’t post other products’ names unless it’s absolutely essential for understanding the problem.

    NoMachine can run on Wayland, in fact we added support for Wayland quite some time ago. You can read about some of the expected behaviour in our documentation here, and possible workarounds:

    Notes for connections to Linux physical desktops running Wayland

    Connecting to a Wayland-based desktop running in a Linux virtual machine


    What I forgot to ask is for the logs, so we can verify that it is the same problem I mentioned. It would be useful to have the logs from the Ubuntu host; you can extract them using the instructions here: https://kb.nomachine.com/DT07S00243 and then submit them directly to forum[at]nomachine[dot]com.

    Can you also show us the output of the following:

    sudo netstat -anlp | grep egl

    if the output is empty, then send the output of

    sudo /usr/NX/bin/nxserver --eglcapture yes and sudo getcap /usr/bin/gnome-shell


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

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