Forum Replies Created
-
Posts
-
Thanks for those, they were useful, so we will continue to investigate this in our labs. In the meantime, if possible add NoMachine to your firewall exceptions (so as not to keep you FW completely turned off). If you encounter any more issues, let us know.
Hi, could you please update to the latest 8.14 release and if you still have issues. If so, I suggest to open a new topic.
Thanks for reporting back. Should any new crash reports be produced (now that you are using 8.14), feel free to send them to us. We’ll keep the topic open for a while so you can submit them here.
psantucc, we are preparing a new package with a possible fix for you to test. We’ll let you know when it’s ready.
Hi, please send us the output of xrandr command run in the remote desktop, and the logs from both sides. You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243 (steps 1 through to 4). Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
Fajny, is it possible that you have installed a 64-bit package on a 32-bit system? This could explain why the library cannot be loaded.
Hi, please send them privately to our email address rather than here. IPs and usernames (not passwords) are present in nxserver.log, nxinstall.log, nxservice.log. If you wish to remove this information before sending, you should edit those in a text editor before sending.
We won’t send a debug package for the moment, at least not for the bad message issue. However we would be interested in seeing that other crash report you mentioned. And the NoMachine logs from the Mac, zip up the entire .nx directory in the user’s home.
Hi,
we checked the logs. It looks like the macOS server ran out of available shared memory, and NoMachine needs to allocate shared memory to work. You can list allocated shared memory segment with the ‘ipcs -m’ command, and you can remove them one by one with the ‘ipcrm’ command, but it would be much easier (and safer) to just reboot the system.
Please also check if you have any crash report for the nxnode process in the ‘/Library/Logs/DiagnosticReports’ or ‘~/Library/Logs/DiagnosticReports’ dirs. If you find them, please send them by email as well. If they were produced by an older NoMachine version, it could still be interesting to have a look.
Still want the logs?
Yes 🙂
I asked the question about new install just to understand if you had seen the exact same error on 8.13 . Send over the logs anyway.Hi, is this the first time you’ve installed NoMachine, or were you using 8.13 beforehand and the problem was also present?
Are you able to send us the logs from both machines? You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243 (steps 1 -3 are for the server, the 4th step is for the client side logs)
Post them here or send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email.
Hi, to not see other computers on the LAN go to Player settings > Security > Network browsing and tick the box “Don’t show other computers on this LAN”. That would have to be configured on each of those other computers.
Can you try to run the ‘xev’ utility in the remote desktop, send the Ctrl key to it through the NoMachine remote session and show us what is reported in the output? I would start with sending any other key first, just to check if everything is set up correctly and the keys are reported in the output. Then you can type just the Ctrl key, to see if it is sent through. Finally, you can try with the problematic Ctrl-<key> combinations and show us the xev output.
We have been unsuccessful at reproducing the issue. Knowing the desktop environment you are connecting to on the Fedora host would be useful, and whether this happens in all applications or specific applications. Copying and pasting to and from an editor, for example, works fine in our tests.
Hi, logs show that that NoMachine is broadcasting correctly. So, we need to understand why your client is not receiving from the problematic Macbook. Either the Macbook 2017 server is not on the same LAN as the client (they must not be subnets), so verify this. And check that the firewall of the 2017 MacBook Pro is not filtering the traffic. You can do that by temporarily turning it off.