Britgirl

[Britgirl]

Any issues in the production-ready Sequoia will become Trouble Reports, which we’ll publish, and they will of course be fixed  🙂

[Britgirl]

Dear macOS Users,

At the moment we are aware of some issues with permissions. It is possible that incompatibilities with this beta will be fixed when Apple officially releases it for production. Please bear in mind that NoMachine cannot officially support pre-release (beta) versions of operating systems. We do of course accept bug reports from users who are testing with these pre-release versions and we work to make sure we are compatible at the time of the general release, in this case macOS 15. We will of course investigate all issues reported and evaluate what fixes, if any, are necessary.

See here for our policies about beta versions: https://www.nomachine.com/AR03E00450

[Britgirl]

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.

[Britgirl]

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).

[Britgirl]

Hi, allowing all keys to get grabbed, except for Alt+Tab which should remain on the client is not possible, I’m afraid.

[Britgirl]

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).

[Britgirl]

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#2

You can send them to forum[at]nomachine[dot]com or attach them here.

[Britgirl]

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:

https://kb.nomachine.com/TR03S10149

[Britgirl]

About the TR being public, not yet, we are going to publish it soon, when it’s ready I will paste the link here.

[Britgirl]

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.

[Britgirl]

It looks to be a known issue,

White screen occurs when connecting to a KDE/Plasma Wayland desktop on Kubuntu
https://kb.nomachine.com/TR07U10921

The patch is planned for the next maintenance, version 8.12.

[Britgirl]

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.

[Britgirl]

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.

[Britgirl]

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?

[Britgirl]

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:

https://kb.nomachine.com/AR10K00728

[Author]

Posts