Forum Replies Created
-
Posts
-
The first article (https://kb.nomachine.com/AR10M00866) is about identifying client devices. It’s an additional layer of security, to limit number of devices from where user can connect. It doesn’t replace user authentication which is still mendatory.
The second article, the one I linked in my reply (https://kb.nomachine.com/AR02L00785) is about using keys instead of passwords for user authentication. It removes the need to provide a password but the user still has to identify himself with a proper username. In that case you have to create at least one key pair for each user. The private key has to be securely stored on each client device from where a given user is connecting. The public key has to be distributed to all the server side hosts where that user needs to be able to log in.
That article is dedicated to configuring the device. Please check this article instead:
https://kb.nomachine.com/AR02L00785 which is for user authentication.
Hi, this is a known issue and a Trouble Report has already been opened. You can track its status using the following link: https://kb.nomachine.com/TR08V11198
Try this instead
nx ALL=(ALL) NOPASSWD: /usr/bin/systemctl start lightdm.service, /usr/bin/systemctl stop lightdm.serviceWe tested on our Debian with XFCE. Nx will have permission to execute sudo without password but only to start/stop lightdm service.
Strange. Our tests on default Fedora don’t reproduce any problems. We set this:
export PATH=”$PATH:/usr/NX/bin”
in .bashrc, and it works.
You mentioned that you had tried disabling HW decoding, but the crash report indicates that HW decoding is still being loaded. You need to “Quit NoMachine player” before changing it, edit the key to<option key=”Enable hardware accelerated decoding” value=”disabled” /> and save. Open NoMachine and start the session.
Please refer to this article for reference:
Thanks for those. It would be useful to also see the submit server-side logs to complete the investigation? You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243. You can upload them here or send them directly to forum[at]nomachine[dot]com.
It seems a system update overwrote some NoMachine system scripts.
You can try running this command on the server from a terminal
sudo /usr/NX/bin/nxserver --eglcapture yes.OK, if the freezing or strange log out happens again, it would be useful to see the logs from the server. 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.
So the logs are not enabled. Just to clarify, the security section of the Player has an option to enable/disable logs using the checkbox. The Server logs are in Server Status, apologies for that.
https://kb.nomachine.com/DT07S00236#2.4
https://kb.nomachine.com/DT07S00236#3.1So all those entries you are noticing are being triggered by some other event. ~240GB of disk space and folders occuping ~30GB should not be happening. As I said, please submit some samples if it starts happening again.
Hi, the logs were not complete unfortunately. We need the .nx directory from the gdm user’s home dir (look for ‘/var/lib/gdm3/.nx’). Reproducing the problem should not be required.
Hi, try disabling hardware decoding in the player. You can do that by setting the appropriate key in the player.cfg file. Instructions are available here:
https://kb.nomachine.com/AR07U01202
You need to set the key to <option key=”Enable hardware accelerated decoding” value=”disabled” /> to completely disable, making sure to quit the player first (from the tray) before then starting a new session.
Does the session still disconnect?
Please send us the client-side logs (the device you are connecting from). You can gather them using the instructions in the following document https://kb.nomachine.com/DT07S00243, specifically paragraph “Fourth Step: Collect Client Side Logs“.
Thanks for the player logs.
A crash is observed:
18874 18874 2024-09-03 09:26:14 034,814 ClientSignal: WARNING! Child process ‘18979’ died because of signal ’11’, ‘SIGSEGV’.
It would be useful to see a backtrace from the core file/crash report. Please see the instructions here:
https://kb.nomachine.com/AR09L00810