Forum Replies Created
-
Posts
-
The logs show that this is not a NoMachine problem. In your case of the big cursor, NoMachine shows it because this is the info that is received from the OS.
Hi, we have not been able to reproduce the problem on the latest 7 version. Incidentally, the latest version of NoMachine was released after you originally submitted this topic, so I need you to confirm that you have the 7.7.4 installed on both sides. We can then send you a debug package.
Hi, it looks more of an issue related to configuration of your set-up. We’re not aware of issues with RSA keys and NX protocol. Did you take a look at this article?
How to set up key based authentication with NX protocol
https://knowledgebase.nomachine.com/AR02L00785If you’ve followed the tips there, maybe tell us the connecting client distribution and version, and then tell us what OS and version it is on the server side. It would also be useful to know what NoMachine product you’ve installed on the server side, and the version of the NoMachine software (both sides). Thanks.
Depending on the links that you followed from the tutorial, you will need with a product from the Linux Terminal Server family or the Enterprise Desktop. All these products are available as evaluation software (30-days) in the Download section of our website:
https://www.nomachine.com/product&p=NoMachine%20Enterprise%20Desktop
https://www.nomachine.com/terminal-server (scroll down to see the details of the individual products)To download any of these, please use this link available in the website menu https://www.nomachine.com/download-enterprise
I’m assuming you restarted both computers after installing?
The error that is shown in the log you attached suggests that the Windows firewall could be blocking the NoMachine connection.
Can you make a quick test? Disable the firewall (this is just for the duration of this test!) on both of the computers and try to connect.
Web-based remote access is not available in the free version of NoMachine. Did you install one of the Enterprise products on the RedHat system, for example NoMachine Enterprise Desktop or NoMachine Workstation? A good place to start is the following tutorial. Is this the manual you were referring to?
https://www.nomachine.com/getting-started-with-web-based-remote-access
What are you connecting to on the server side? You mentioned Linux, but not the NoMachine product. What distribution of Linux and what version? This would be useful information to have. Thanks!
If the Macs are going to sleep, it’s normal that you can no longer see them in Machines of the Player: the Mac suspends applications and this means that broadcast information of the NoMachine server on the LAN is no longer received on the NoMachine clients.
There are two things you can try:
1) Configure the Macs’ Energy Savings appropriately so they don’t go to sleep.
2) if number 1) is not an option for you, create connection files using the LAN IPs of those Macs and store them on the computers/devices you are connecting from. Use these to start the connections (they are identifiable with the small !M icon in Machines) from the Player.
If the connection still fails to properly wake up your Macs, edit the configuration of the connection visible in the Machines list, and tick the box “Wake on LAN” (Right click on connection icon -> Edit connection -> Configuration -> tick box).
Let us know the outcome.
Hi, we reproduced the issue and have opened a Trouble Report.
Client window ignores keyboard input on macOS Monterey
https://knowledgebase.nomachine.com/TR01T10443A fix will be released in next but one update. I say “next but one” because a v7 maintenance is almost upon us.
Hi, thanks for submitting the additional information. We’re not aware of similar behaviour.
To understand why it’s happening we would need to see a full set of logs, from both sides so a set from your Ubuntu client and then from the Windows computer which you are connecting to.
Please see here for instructions. https://knowledgebase.nomachine.com/AR10K00697
You can send attachments directly to forum[at]nomachine[dot]com using the topic title as the subject of your email.
@ mcvitas, please check your email inbox. I have sent you further instructions on how to get logs to us. Thanks!
Did you already check that the box “Don’t advertise the computer on the network” is not flagged on the Mac machines?
The NoMachine MDNS service uses the UDP port 5353. Check whether the firewall on those Mac computers is maybe blocking access to it.
Hi, we’ve logged your interest in testing a native package of NoMachine for Windows ARM. It’s certainly not a technical limitation to port NoMachine to run natively on Windows ARM, and it’s definitely something we’d like to offer in the future. Adding support for new platforms in our future roadmap is purely a business choice. Although the Windows on ARM segment offers more choice in terms of hardware available (it wasn’t like that a couple of years ago), it still shows a somewhat lacking ecosystem compared to Intel and AMD products on the market. In the meantime, we’re keeping an eye on Windows for ARM increasing popularity and if we have a pre-release package available for testing, we’ll announce it here 😉
We reproduced the same behaviour. But this seems to be more of a problem of Mint and not NoMachine. It can be fixed by setting the environment varible in node.cfg:
DefaultDesktopCommand "env XDG_CONFIG_DIRS=/etc/xdg/xdg-xfce:/etc/xdg:/etc/xdg /usr/bin/startxfce4"This should be enough to get the correct desktop GUI. Since the desktop-user was already logged and probably you had “wrong” settings saved, you need to reset it with:
rm -rf /home/desktop-user/.config/xfce4and then logging in to your NoMachine session should give you the desired DE.
This is not caused by NoMachine software. This is because the virtualized OS X does not recognize the original hardware, so you should check your hypervisor settings.
This example may help depending what you are using: https://stackoverflow.com/questions/70186036/icloud-unsupported-device-when-installing-macos-big-sur-in-vmware