Britgirl

[Britgirl]

The player window, once you’ve resized it to the size you want, should keep the same dimensions next time you start that session (using the same .nxs file).

Can you give some more details about what you are trying to achieve? You say “but I only can resize client window by mouse move,” what do you mean exactly?

[Britgirl]

Whilst we take a closer look at what possible options are available to you, I’ll explain what nxhtd is. This is the NoMachine Web Player (our web server) component which permits NoMachine server to accept incoming remote desktop connections from a browser. This is only available in the enterprise-oriented range.

[Britgirl]

I’d also like to add a note about resolution since this is what the topic was originally about. Arch and PAM problems aside 🙂 the resolution of the physical desktop depends directly on the system settings and what your graphics card supports and not NoMachine. This means that when you are connecting to the physical display, NoMachine can show you the display according to the resolution sizes available with the graphics card installed and these will show in the Display settings of the Connection Menu. In a physical desktop session, the resolution on the client cannot be changed to one that is not supported by the remote GPU. More about this is explained here:

Some tips about resize and scaling options for NoMachine remote desktop software
https://kb.nomachine.com/AR02M00835

[Britgirl]

There was a similar problem with Arch and Pam a while back (desktop not showing) and there was a solution. Arch is not amongst our supported Linux, but we will do our best to provide as much help as possible to allow users to install and use NoMachine. This is the earlier topic: https://forums.nomachine.com/topic/connection-fails-on-headless-client#post-21783

Anyway, we checked on the fly to see if something had changed since then, which it has.

1. Create a backup of nx PAM configuration (sudo cp -a /etc/pam.d/nx /etc/pam.d/nx.original). Then change /etc/pam.d/nx in this way:

auth include system-login
account include system-login
password include system-login
session include system-login

2. Change DefaultDesktopCommand in /usr/NX/etc/node.cfg in order to have this on KDE case:

DefaultDesktopCommand "/usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/startplasma-x11"

3. Stop display manager:
sudo systemctl stop display-manager

4. Restart NoMachine:
sudo /etc/NX/nxserver --restart

This worked for us.

[Britgirl]

Can you tell us the Linux distribution and version? What desktop enviroment is it?

[Britgirl]

Hi, the name of the product can be obtained either by running from command line nxserver --version or from the /etc folder which contains the server.lic file (which will show you the name of the installed product).

[Britgirl]

It was working in the morning & early afternoon and suddenly stopped working.

Please update to the latest version and if the issue reoccurs, submit the logs from the NoMachine server side. Send them to forum[at]nomachine[dot]com.

https://kb.nomachine.com/DT07S00243

[Britgirl]

We were able to reproduce similar behaviour and have opened an internal Trouble Report for the moment. The problem appears on Squid3 configuration on newer systems (reproduced on Squid configured on Ubuntu 20.04 and Redhat 8) and can be reproduced with both NX and SSH protocols. Settings without username and password authetication work fine. The exact same Squid3 proxy with password configuration set on Ubuntu 12.04 works fine with NoMachine. The fix will be made available in the upcoming v8.

[Britgirl]

Hi, on what version of macOS are you encountering this?

[Britgirl]

Hi Sam, just to confirm we got your nxclient.log. We’ll come back to you with an update.

[Britgirl]

We are not aware of similar issues on Debian 11.

The “S-log” excerpts you pasted are not from NoMachine. If you have an NX legacy or derivative installed on that machine, or had it installed, I would suggest to uninstall NoMachine and remove all traces including the home, reinstall NoMachine and start again, making sure that you’ve also removed any trace of what other product you might have had (even inadvertently) on that machine.

sudo dpkg --purge nomachine 
sudo rm -rf /usr/NX /etc/NX /var/NX .nx

Then reinstall the NoMachine product of your choice.

You should check server-side logs (which are in /usr/NX/var/log) – not client.

For your reference:

Collect server side logs automatically
https://kb.nomachine.com/DT11R00182

or

Collect server and client logs manually
https://kb.nomachine.com/DT11R00181

[Britgirl]

Default Ubuntu 20.04 installs and works out-of-the-box in our labs.

Are you running Wayland and is it a VM? If so, take a look at this article and follow the tips there:

Connecting to a Wayland-based desktop running in a Linux virtual machine
https://kb.nomachine.com/AR04R01083

You could also log out and then log in, but to a X.org desktop. This will show whether the problem is Wayland or not.

Send the logs by all means, we can take a look and see what’s going on. Please send them to forum[at]nomachine[dot]com making sure to put the title of your topic as the subject of your email. Thanks!

[Britgirl]

The output shows that PulseAudio libs are present but not that PulseAudio is installed and being used. Fedora 36 now adopts Pipewire instead of PulseAudio and it is likely that it is using those libraries.

https://fedoraproject.org/wiki/Changes/DefaultPipeWire

 

Support for Pipewire in NoMachine will be added in v8.

So first install PulseAudio:

sudo dnf install pulseaudio

Fedora will ask you to remove Pipewire and replace it with PulseAudio. Then you can install NoMachine again or use command from installation output:

/usr/NX/scripts/setup/nxnode --audiosetup <path>

to configure PulseAudio with NoMachine.

[Britgirl]

Hi, thanks for reporting this. We’ve also reproduced it on the iPadOS 16 beta. We will queue up for fixing in our next mobile release.

[Britgirl]

This topic was closed because we received no logs or further output as requested.

[Author]

Posts