Britgirl

[Britgirl]

Investigations that were done did not allow us to pinpoint specific system variables which are affecting the NoMachine UI. However, some improvements recently made could help, and we invite you to update to the latest version. If you are still encountering the same issue, please follow the instructions that were recently posted for a similar topic here: https://forum.nomachine.com/topic/nomachine-ui-stops-working-enabling-linux-for-windows#post-55834

And then reach out to us through the website, so we can continue through our traditional support channel. You can contact us using the following email address issues[at]nomachine[dot]com.

[Britgirl]

Investigations that were done did not allow us to pinpoint specific system variables which are affecting the NoMachine UI. However, some improvements recently made could help, and we invite you to update to the latest version. If you are still encountering the same issue, please follow the instructions that were recently posted for a similar topic here: https://forum.nomachine.com/topic/nomachine-ui-stops-working-enabling-linux-for-windows#post-55834

And then reach out to us through the website, so we can continue through our traditional support channel. You can contact us using the following email address issues[at]nomachine[dot]com.

[Britgirl]

Hi, NoMachine disconnects when the Mac goes into hibernation, and then reconnects when it wakes up. What you are seeing is the correct behaviour even though you didn’t physically disconnect and reconnect NoMachine.

Thanks for submitting the logs, they confirm what I wrote previously:

Info: Remote desktop resized to 3840×1200.
Info: Session window surface configured.
Info: Changing display mode to ‘viewport’.

Upon reconnection, NoMachine tries to apply the previous resolution before it disconnected, but can’t because the macOS desktop (not NoMachine) decided the resolution should be 3840×1200. So it switches to ‘viewport’ because the client has a smaller available resolution.

[Britgirl]

Hi, we’ve reproduced this and opened a Trouble Report here: https://kb.nomachine.com/TR07X11880. For the time-being you should use a different key for switching the layout (or a combination). Please use the link to keep track of the TR’s status. Thanks for reporting 🙂

[Britgirl]

Hi, thanks for those, they helped us to identify where the issue is. We are going to send you an updated library with a potential fix. Please download and install, the same as you did previously and let us know if it fixes the issue.

[Britgirl]

Hi, there is a trouble report open related specifically to Gnome, here’s the link https://kb.nomachine.com/TR03V11117. There is no other workaround other than login to the physical session first (before creating virtual session on gnome), or use an alternative desktop session (not Gnome).

[Britgirl]

Hi, when connecting from the problematic Debian 13, can you confirm that you cannot send input events to both the Windows 11 machine and the other Debian 13? If so, this is an indication that the problem is on the client side. Client side logs would be useful. On the problematic Deb 13 computer -> Player Settings -> Security and check option ‘Don’t delete log files on exit’. Connect and reproduce the problem. Afterwards go back to the Player Settings and click “Take logs”. You can attach them here or send directly to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks.

[Britgirl]

We have not been able to reproduce and the logs don’t give any indication of an error. You could try checking the xev application output. It should say something more when the tab is pressed. Start xev in the session. Press Alt+Tab, copy output from xev window, and paste here.

[Britgirl]

create / use a key pair between my iPad and my Mac mini – I’m figuring that would be more secure than a username / password?

Hi, for key-based authentication take a look at the article here which explains how to set it up: https://kb.nomachine.com/AR02L00785.

I would also like to prevent the NoMachine server on my Mac from registering / publishing my Mac on the NoMachine cloud.  I’ll plan on just VPNing in and accessing my Mac via IP address (I use DHCP reservation on this Mac)

NoMachine does not automatically register/publish a machine on Network unless you or a user with full admin privileges explicitly tell it to 🙂 But if you want to make sure it doesn’t accidentally get published for whatever reason, you can disable it completely in the configuration file and to do that, check this article here: kb.nomachine.com/AR06W01278.

and finally, just b/c I’m paranoid I’d like to restrict inbound connections to an IP range used by my firewall when connecting in via WireGuard.  I know I can do that in PF on the Mac – but wasn’t sure if that was the best / most elegant solution

To restrict an incoming over IP connection to a specific range, you can do using your router/firewall configuration. What is possible within the server configuration file is to lock down which interface the nx server daemon is listening. You can do this with NXdListenAddress in the server.cfg file. It does not accept a range of addresses currently, that’s coming in version 10. You can also prevent the machine from broadcasting on LAN, it will still be reachable through creating a connection, but it won’t show up in other NoMachine users’ Machines panel if they are also on your same LAN.

#
# Enable or disable broadcasting the required information to let
# other computers discover this host on the local network.
#
# 1: Enabled. Other computers on the local network can find
#    this host machine.
#
# 0: Disabled. This computer cannot be found on the local
#    network but it’s still reachable by providing its IP
#    or hostname.
#
EnableLocalNetworkBroadcast 0

[Britgirl]

Hi, while we continue to monitor reports, investigate issues, and identify potential fixes for issues we are seeing on the macOS Golden Gate preview, we generally prefer to hold off on releasing those fixes while the operating system remains in beta. Beta releases can change significantly before the final version becomes available, and a fix implemented today may need to be revised, or even undone entirely, as Apple continues to make changes throughout the beta cycle. For this reason, we typically wait until the operating system reaches its official release before finalizing and delivering NoMachine fixes. This helps ensure that any changes we make are stable, effective, and won’t require further rework as the platform evolves. We appreciate your understanding and thank you for helping us identify potential issues ahead of the macOS official launch. We also appreciate your offer to test in advance 😉

[Britgirl]

Hi, thanks for submitting the logs, we have reproduced the issue. It’s related to libnxegl not being preloaded due to system scripts not being updated correctly on Armbian. A Trouble Report has been opened. Please use the following link to monitor its status: https://kb.nomachine.com/TR07X11883.

[Britgirl]

We’d still like to have new logs if that’s possible. From that last set, we see that you installed the library, but you didn’t reproduce the problem afterwards 🙂

[Britgirl]

Hi, you can send the logs to forum[at]nomachine[dot].com. Please use the title of this topic as the subject of your email. Thanks!

[Britgirl]

Hi, logs don’t show any new connection attempt after replacing the library. Please connect to the server again, reproduce the problem, then gather new logs.

[Britgirl]

Hello,

thanks for your patience. We analyzed the logs, but they don’t show any error, nor give an indication of where the error could be. To proceed further, we would like to see logs from both the working and the non-working case, so that we can compare them.

[Author]

Posts