Forum Replies Created
-
Posts
-
Hi, can you enable debug and gather logs from the Windows machine? You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243. Enable debug, connect from Mac to the Windows server to reproduce the problem and then extract the logs.
Attach them here or send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
should NoMachine even be able to connect through a VPN on the router where the IP is on a separate subnet while the mac is in standby
NoMachine’s WOL won’t be effective in that case.
So we can close the topic. I only suggested to gather logs if the problem of not being able to connect persisted. But this seems to be solved 🙂
It could be that you are encountering this known issue:
Cannot use 4096 bit RSA keys for key-based authentication in web sessions
https://kb.nomachine.com/TR08Q09394Please try the available workaround.
Hi, can you tell us what Windows OS version it is? Did you try clicking “update driver” in the Windows dialog (left of image)? Are you using a USB hub maybe?
In the meantime you could trying disabling the NoMachine drivers and see if that helps.
How to disable or uninstall NoMachine USB drivers on Windows
https://kb.nomachine.com/AR12O00955Hi, what deb distribution are you running, Cinnamon or XFCE? We’ve heavily tested both and don’t have any issues. A “wrong deb package” such as 32-bit instead of 64-bit or vice-versa would still open.
Can you try starting player from the command line ( /usr/NX/bin/nxplayer)? What is the output?
It would also be useful to check the NoMachine logs and even the system logs of the affected installation.
Hi, it’s not clear to us what you tried doing. Can you send us the NoMachine logs of both the Windows (client) and the Sonoma (server) machines? You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243. There are 4 steps to follow. The fourth step is for the device you are connecting from.
Attach them here or send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
In any case, perhaps the separate network timeout when in standby is something that should have been reported and investigated before now.
We’ve not seen any issues with 1) the automatic software update dialog blocking remote access for NoMachine and 2) nor interfering with other applications in our tests. No other users have reported similar issues.
Please confirm: are you able to connect with NoMachine now? Are you also able to connect with NoMachine when the Mac has gone to sleep? Next time, if you have problems when connecting with NoMachine, the best thing to do is to zip up the entire .nx home directory on the Mac server and send it over, and we can take a look. If you encounter a problem which is reproducible, then in that case, enable debug first, reproduce the problem and send us the logs. The steps to reproduce the problem would also be useful to us. Here is the link to the instructions in case you need them next time: https://kb.nomachine.com/DT07S00243.
CRCinAU,
sorry for the confusion. I realise now that you fixed the issue for which you opened this topic by changing some configuration keys (https://forum.nomachine.com/topic/fedora-40-nomachine-not-working#post-48741). My bad.
Just to clarify what we had written about another issue you mentioned, related to resolution/resize, there is no change. This is what we wrote last time about Wayland after looking at your logs, “NoMachine handles the resize correctly but then the desktop fails to adapt. You mentioned that you have this problem with startplasma-wayland, but not with startplasma-x11. Even when running the Wayland command, the virtual desktop will fall back to using X11 in any case, because that is the only protocol that NoMachine virtual desktops support at the moment. So the recommended command is startplasma-x11.”
I have split your issue to create a new topic as it looks to be a totally different problem. (old topic is https://forum.nomachine.com/topic/after-upgrade-to-ubuntu-24-04-1-lts-players-immediately-disconnects/page/2).
Can you look for core files of the nxplayer and submit the backtrace?
Hi, in my last post I suggested to try monitoring the system calls when the player starts. I’ll paste my old reply here for convenience…
We don’t see much difference in the processes besides the Memory Integrity being enabled only on the troublesome system. We can only assume that the differences must lie in the way the two machines are configured. Maybe monitoring to know what happens in system calls could be useful when the player starts?
i) Download Process Monitor https://docs.microsoft.com/en-us/sysinternals/downloads/procmon (it doesn’t require installation)
ii) Right-click on Procmon.exe and select “Run as administrator”
iii) Click on “Filter” in the top menu, then “Filter…”, click “Add” and set the filter:
* Column: Process Name
* Relation: is
* Value: nxplayer.bin
iv) Click “Add” then “Apply”.
v) Click on “File” then “Clear”
vi) Start the NoMachine client, and let Process Monitor capture data for about 30 seconds
vii) Click the magnifying glass icon in the toolbar to stop capturing
viii) Click “File” in the top menu, then “Save…” (PML file)
ix) Create also a TXT summary. Click “File” > “Export…” > “Text File”an you enable debug, reproduce the problem and submit the logs so we can check? If needed, I can spin off your thread if it’s a different problem.
Chatter5352, just to clarify, we don’t need to send you a debug package for the SSH issue because you we now know that you are using the free version which doesn’t support incoming SSH connections. If you are still experiencing the session freezes, we would be interested in seeing the server side logs (see Guro’s post just above). Let us know.
Hi, sorry for not updating you on the situation with the fix after your penultimate post. I thought I had. Good to know that the update has fixed your issue. In the 8.14 release there is the fix for https://kb.nomachine.com/TR03U10784, one of the problems you were encountering. Let us know if you encounter further issues.