SteveW

Forum Replies Created

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • SteveW
    Participant

    Thanks, but… actually, I did reboot after making the suggested changes following Option #2. Perhaps my post wasn’t very clear, though. Both Option #1 and #2 did indeed solve the initial problem of not being able to view the remote physical desktop session. I am able to do that now whether I use Option #1 or #2.

    The next problem I encountered, though, is that if at any time the remote desktop session becomes locked through the Gnome screen lock I can no longer view the remote desktop. All I see is a black screen and a moving cursor that tracks the mouse. The error messages in the server log seem to point to the cause:

    Process ‘/bin/dbus-send –type=method_call –dest=org.freedesktop.ScreenSaver –print-reply –reply-timeout=1500 /ScreenSaver org.freedesktop.ScreenSaver.Lock’ with pid ‘13661/13661’ finished with exit code 1 after 0,007 seconds.

    Lock screen command finished with error ‘Error org.freedesktop.DBus.Error.NotSupported: This method is not part of the idle inhibition specification: https://specifications.freedesktop.org/idle-inhibit-spec/latest/\n’.

    It looks to me like the screen saver in this upcoming release of Ubuntu doesn’t recognize the dbus command being sent to it from NX.

    Thanks!

    SteveW
    Participant

    Hi,

    Thanks for that suggestion. I gave it a try and see the same results as with Option #1. With both options I can establish a working connection to a physical desktop on the remote machine but only if the remote desktop is not locked using the Gnome screen lock.

    I’ll attach the log files. It looks like NoMachine may be issuing an unrecognized dbus command to the screen saver in this new version of Ubuntu.

    Steve

    SteveW
    Participant

    Using Option #1 in the following Knowledge Base article now lets me connect to an existing physical session on an Ubuntu 26.04 (Wayland) server:  https://kb.nomachine.com/AR04R01083.

    And that works as long as I’ve already started a physical session on the server. If there is no active session on the server, I’m still left with a black screen on the client along with working keyboard entry and mouse movement.

    Additionally, if I do have an active session on the server and successfully connect to it from my client, then the client will freeze (and remain frozen…) if I lock the screen from either the client or the server session. I should probably report this second problem separately to the forum.

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