Forum Replies Created
-
Posts
-
Hi, 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.
Ok , thanks for letting us know. We need a couple of days to prepare it. I will send you a private link when the packages are ready.
We need debug logs like before. I’ll paste the link to the instructions for convenience, https://kb.nomachine.com/DT07S00243. Enable debug, reproduce, zip up and send them to forum[at]nomachine[dot]com or attach them here.
I’m not sure what “it” there would be to try beyond connecting or if you meant connecting should automatically trigger a wake up (in which case I try every time).
Sorry I updated my post to be clearer 🙂 The “it” was referring to our wake-on-lan feature. It was not clear how you were “waking up” your mac and I had assumed, erroneously, that you were referring to wake-on-lan.
For reference with regard to the waking up the mac part, there was a time when I had to use [removed] first every time, and I thought that was a mentioned as a known issue to be fixed in the future on these forums, but this was quite a while back.
You posted https://forum.nomachine.com/topic/nomachine-quit-working-after-mac-sleep-disconnect-not-blank-screen-issue, but I believe we received no logs because you couldn’t reproduce the problem? But we can start a fresh investigation now that we know the macOS version. We’ll come back to you soon.