Forum Replies Created
-
Posts
-
Hi, is it possible for you to send those logs to us so we can take a look? Send them to forum[at]nomachine[dot]com. Thanks.
Hi, sorry for the delay in coming back. It’s not good news. We looked at the last set of debug logs and they still don’t pinpoint to the specific problem. What we do know is that a parameter that NoMachine relies on when performing GPU encoding is not being recognized. The error is “Invalid parameter”, but we’ve not been able to pinpoint which specific parameter despite the high level of logs and we’ve been through every single parameter we use. These are our standard parameters, and permit GPU encoding across several dozens of combinations of macOS systems and hardware combinations with diverse video cards. It’s possible that this particular encoder doesn’t support one of the features that we need, hence the Invalid parameter error. As for the other apps which you say are using the GPU, they are most likely using a different set of parameters. We could of course continue debugging on our own by replicating your set-up to a tee, purchasing the hardware and AMD RX 560 and disabling the parameters one-by-one until we find which parameter is causing the issue. But it would not bring us to a solution because it would not be possible to change the way NoMachine uses the encoder. So, the workaround is to continue using software encoding (or if possible try an alternative GPU unit).
Hi, allowing all keys to get grabbed, except for Alt+Tab which should remain on the client is not possible, I’m afraid.
Check your permissions.
home/essin/.Xauthority not writable, changes will be ignored 368745 368745 2024-06-17 12:02:52 026.353 NXNODE WARNING! Cannot remove cookie for :3002 from /home/essin/.Xauthority. 368745 368745 2024-06-17 12:02:52 026.374 NXNODE WARNING! Error is: 13, Permission denied.It is just a warning, but maybe this is blocking the connection.
Check /home/essin/.Xauthority permissions and change the owner to essin (sudo chown essin:essin /home/essin/.Xauthority) or just remove the .Xauthority file (it will be re-created when you connect again).
We need to see NoMachine server-side logs. These must be taken from the machine you are connecting to.
Instructions are here:
https://kb.nomachine.com/DT07S00243#2You can send them to forum[at]nomachine[dot]com or attach them here.
Please disregard my previous explanation about the bug related to smartcard forwarding. This was a misunderstanding on my part of what developers had been investigating and their findings. The Trouble Report for your issue is available at the following link:
About the TR being public, not yet, we are going to publish it soon, when it’s ready I will paste the link here.
We have a Trouble Report open in relation to forwarding smartcard which does not work correctly when the automount option is enabled. It’s caused by some changes introduced to the ssh-agent in an OpenSSH update which, in order to increase the security level, block the execution of PKCS#11 libraries not in the default path or in the verified path. Smartcard will be mounted correctly after user navigates manually to smartcard panel in the menu to add it there. Btw, general improvements to device forwarding are coming in the release of NoMachine 9, including the possibility to detect devices newly plugged in during the session.
It looks to be a known issue,
White screen occurs when connecting to a KDE/Plasma Wayland desktop on Kubuntu
https://kb.nomachine.com/TR07U10921The patch is planned for the next maintenance, version 8.12.
Our initial tests show that it’s necessary to uncomment the “DefaultDesktopCommand” key in the node.cfg.
#For GNOME session:
DefaultDesktopCommand "env XDG_SESSION_TYPE=wayland dbus-run-session /etc/X11/Xsession gnome-session"#For XFCE:
DefaultDesktopCommand "dbus-run-session startxfce4"Maybe you could try these.
The logs show that screen sharing is disabled. This suggests either that “Desktop Shared” is not enabled. You can check this in the NoMachine Server settings on the Debian host.
Or that in Security -> Desktop Access, you have unticked “Don’t allow the owner of the desktop to connect if the desktop is not shared”. Are you always connecting from remote as the owner of the desktop? By “owner”, I mean the same user account that is actually logged on the Debian server.
The free version of NoMachine supports one incoming connection to the system. Have you always been using the free version? Maybe you installed the free version thinking you were installing one of the other products?
Hi, SSH sessions are possible when the server side has a product from the Enterprise suite installed. It’s definitely possible to run an NX session through an SSH tunnel. Check out this article for the instructions:
Hi Sven, thanks for coming back with your findings and the link. This is indeed a bug with the nvidia drivers and not something that we can fix in the NoMachine software.
Hi Jon,
The free edition of NoMachine is for access to the physical display, so it’s the correct behaviour. Maybe what you are looking for is NoMachine Workstation from the Terminal Server family for Linux? Check out the differences here: https://kb.nomachine.com/AR10K00702. The Workstation is available to download here: https://www.nomachine.com/product&p=NoMachine%20Workstation.