Forum Replies Created
-
Posts
-
Hi, how strange. Can you tell us the exact version of macOS you’re connecting to? Do you have any applications open or running in the background on the macOS when you try to connect?
I take it this is the latest version of NoMachine on both sides, client and server? Logs from both sides could be useful, taken when you can reproduce the problem. You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
The forums are currently separate from the Customer Area. So you have two logins: one for the public Forums where anyone can answer, and one for the Support Center for those with valid subscriptions which is a direct line to the NoMachine Support Team. This is going to change in the future when users will only have to register once. In any case, we would still recommend users with subscriptions submit their questions through their customer area rather than the forums.
The steps are:
1) In the Menu, select Get Support
2) insert your Customer ID and password
3) select Support Enquiries in the navigation bar
4) Click Open a Support Enquiry
More info is available here: https://kb.nomachine.com/AR08C00243
If you are not in possession of your Customer ID, please write to us via the website (Contact us) and include the License Id from the license file you are using.
Hello,
as an enterprise user you also have the option to open a support enquiry from your customer area.
Take a look at the tips here for headless Linux hosts:
https://kb.nomachine.com/AR03P00973
If the tips there don’t help, then we’ll need logs from the Linux side. You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email.
Also the output of
sudo grep -E "DefaultDesktopCommand|CommandStartGnome" /usr/NX/etc/node.cfgIn our environment CentOS 7 default settings show:
DefaultDesktopCommand "/bin/dbus-launch --exit-with-session gnome-session --session=gnome" CommandStartGnome "/bin/dbus-launch --exit-with-session gnome-session --session=gnome"So you can print regular letter size sheets. The problem is printing labels only on Catalina, correct? On Sonoma, printing pauses.
We need to see the logs from both sides (OS host you are connecting from and the macOS you are connecting to when you reproduce the two separate issues. See the following document for full instructions and send everything to forum[at]nomachine[dot]com. https://kb.nomachine.com/DT07S00243
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
Hi, you didn’t mention what OS your connecting from and what distribution and desktop environment on Linux side you’re connecting to. Knowing why mouse and keyboard are not working when you connect over Wifi, but do work when you connect over a hotspot is difficult to say. We need to see the logs from both sides (the Linux server side but also on the player device you are connecting from). See the following document for full instructions and send everything to forum[at]nomachine[dot]com. https://kb.nomachine.com/DT07S00243
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
Logs show that Wayland is enabled. Please make sure that Wayland is disabled, reproduce the problem and submit brand new logs.
Hi, the screenshot didn’t attach, can you submit it to forum[at]nomachine[dot]com and we will upload it to your topic. Thanks.
It looks related to this Trouble Report:
White screen occurs when connecting to a KDE/Plasma Wayland desktop on Kubuntu
https://kb.nomachine.com/TR07U10921Try disabling Wayland and using X.org instead. Does that help?
We are producing a similar behaviour and it seems to be caused by a recent nvidia drivers update. You have version 545 (libnvidia-encode.so.545.29.06). Can you downgrade to 535 and tell us if the problem disappears?
Before you downgrade to try, please send us the logs from the NoMachine server. You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243. Send them directly to forum[at]nomachine[dot]com making sure to use the title of this topic as the subject of your email. Thanks!
We have checked MX Linux and have not been able to reproduce any similar behaviour. It would have been useful to know the desktop envirionment on the MX Linux system. It could well be x.org crashing. What’s not clear is your setup. Are you are using MX Linux on the Raspberry or are you using a MX Linux NoMachine client to connect to the Raspberry? If the latter, what is the OS and desktop env is on the Raspberry? If you wish for us to investigate further, please provide us with the full set of NoMachine logs as requested from client and server sides? (link in previous reply).
edit: in your case, using Wayland instead of X.org could help.
Hi, do you have a second monitor attached to the M1 laptop? We can reproduce this behaviour if another monitor is attached to the laptop. If this is not your case, please describe precise steps to reproduce.
Hi, we will be adding a timeout parameter to the scripts. This will allow you to set a timeout that fits your custom script setup.
so for example,
UserScriptAfterLogin "/usr/script/afterLogin.sh --timeout 180.This will be implemented for version 9.
The most reasonable implementation would be to send a WOL packet just before the connection attempt, so that if the server is not running, it would restart its run, or send the WOL packet if the server is not immediately responding in a reasonable time, like a couple of seconds. The WOL packet, instead, is now sent after the connection timeout, if the remote host is not responding. The reason it was done like this was to overcome a few WOL problems and incompatibilities we encountered at the time of the first implementation. We actually retested all of this and it doesn’t seem that these problems and incompatibilities still hold. This means that a more reasonable implementation should come shortly, actually resolving the problem you detected. Thanks for reporting.