February 4, 2020 at 17:03 #25475
We have some problems trying to configure the “EnableLockScreen” feature.
We have installed the NoMachine Enterprise Desktop (v6.8.1) into our SLES 12 SP3 VM. The service is working fine, as we are able to access the physical desktop from a NoMachine client.
The problem is that, after the disconnection of the NoMachine client, instead of locking the physical desktop with the native lock screen, sometimes it shows a screen saver instead, which reports “User: nx@<hostname>” and asks for a password.
The problem is that the password requested seems to be for the “nx” user, which is the user assigned to the service and not the user used to access with the NoMachine client. This provokes that the physical desktop gets locked unless a reboot is made.
Our expected behaviour is that each time all NoMachine connections are closed, the screen is always locked with the user logged and using the GDM lock screen.
What are we doing wrong?
Best regards and thanks in advance,
EdnaiulFebruary 5, 2020 at 11:46 #25496kroyContributor
We couldn’t reproduce this problem. Which Desktop Environment do you use and which screensaver? If you try to lock screen manually inside the session are you reproducing this behaviour?February 6, 2020 at 11:09 #25509
Thanks for your quick reply Kroy
We’re using GNOME Version 3.20.2, and the only screensaver package installed is xscreensaver 5.22. However, if I execute the following command on a console:
$ screeensaver-command -version
The answer is the following:
xscreensaver-command: No screensaver is running on display :0
So it seems that gnome is not using a screensaver, which makes sense as searching the graphic options this feature doesn’t appear (is not included).
When we lock the user session using the gnome option in the user menu (where “Log out” and “switch user” are located), the usual GDM login screen appears requesting the password for the correct user (as well as the option to Log in as another user).
Maybe NX is calling to a different desktop environment or xscreensaver?February 6, 2020 at 13:22 #25511
Logs might help to identify your issue, so please enable debug, than reproduce your problem, collect and send logs to us. This article shows how to collect logs: https://www.nomachine.com/DT10O00163
Please submit them to forum[at]nomachine[dot]com putting the title of your topic as the subject.February 10, 2020 at 13:02 #25553
Today we’ve repeated our scenario to generate the requested logs (which have been already sent to the e-mail address provided).We have checked the nxserver.log and the nxerror.log and we have determined that the issue is around the datetime 2020-02-10 10:06:25.
A few messages that could lead to the solution could be:
2020-02-10 10:06:25 453.810 3326 NXNODE Cannot lock screen using dbus message. Trying to use screen lock application.
2020-02-10 10:06:56 705.600 3326 NXNODE WARNING! Lock screen command finished with error ‘xscreensaver-command: no screensaver is running on display :0\n’.
2020-02-10 10:08:29 041.891 3326 NXNODE WARNING! Process ‘/usr/bin/xdg-screensaver lock’ with pid ‘4349/4349’ finished with exit code 4 after 0,078 seconds.
2020-02-10 10:08:29 042.608 3326 NXNODE nxProcessCreate: ‘/usr/bin/xlock’ ‘/usr/bin/xlock /usr/bin/xlock’ ‘DISPLAY=:0 HOME=/var/NX/nx XAUTHORITY=/usr/NX/var/log/node/C-ttcf-sv-mcu-1001-76769C47615E9631BAA73D1386A97DC5/authority XDG_SESSION_ID= XDG_SESSION_PATH=’ ’18’ ’24’ ’24’ ‘101’February 10, 2020 at 17:06 #25557
It’s not clear why we aren’t able to lock with dbus, but problem here is this part: HOME=/var/NX/nx, nxnode is run as desktop owner so home directory should be desktop owner’s home directory, so HOME shouldn’t point to /var/NX/nx, Are you maybe using UserNXDirectoryPath? It could be related to problem described in this TR: https://www.nomachine.com/TR09Q09406
If that’s the case, then updating could help.February 10, 2020 at 17:28 #25560
We are not using Virtual Desktops, and the value of the UserNXDirectoryPath is set to the default value (“”). It seems like, after the disconnection of the last user, something “forgets” the logged user and falls back to the information of the nxserver service user (“nx”).
In the other hand, when the “default” locking mechanism fails (xdg-screensaver lock), it seems to try with a different one (xlock).
I’m a bit confused about this, because we have still not been able to define the exact steps to reproduce the problem. Also, in some cases, the xlock screensaver is shown and in others not.February 11, 2020 at 12:55 #25584
Full logs could shed some light on what’s going on, so please send logs to forum[at]nomachine[dot]com set specify troubles-with-enablelockscreen as Subject.
It’ll be good to know what are steps to reproduce this issue and how often that happens. I’d like to see also effective user of all nodes, and might be better to see all processes related to NX, so please send output of:
ps -ef | grep nx
along with logs.February 11, 2020 at 13:06 #25589
Full logs have been sent again to the provided e-mail.
Regarding the command, here you have the output:
nx 4978 1 0 09:41 ? 00:00:00 /usr/lib/systemd/systemd –user
nx 4981 4978 0 09:41 ? 00:00:00 (sd-pam)
nx 5096 1 0 09:41 ? 00:00:00 /bin/dbus-launch –autolaunch 38a12291fe576b5d1961376a5c129794 –binary-syntax –close-stderr
nx 5097 1 0 09:41 ? 00:00:00 /bin/dbus-daemon –fork –print-pid 5 –print-address 7 –session
nx 6171 1 0 09:44 ? 00:00:00 /usr/bin/pulseaudio –start –log-target=syslog
nx 8835 1 0 10:04 ? 00:00:08 /usr/NX/bin/nxserver.bin –daemon
root 8972 8835 0 10:04 ? 00:00:00 /usr/NX/bin/nxexec –node –user nx –priority realtime –mode 0 –pid 11
nx 8976 8835 0 10:04 ? 00:00:00 /usr/NX/bin/nxd
nx 8984 8972 0 10:04 ? 00:00:00 /usr/NX/bin/nxnode.bin
nx 9026 8984 0 10:04 ? 00:00:00 /usr/NX/bin/nxclient.bin –monitor –pid 4820February 11, 2020 at 15:16 #25591
Are you logged into system as user ‘root’? Seems like we do have problem in that case, but it’ll need investigation to find if/how that could be fixed.February 11, 2020 at 15:50 #25593
Yes, probably the trigger condition is to leave the physical screen with the “root” account logged. I cannot confirm, but in our tests the problem seems to appear only in that scenario.
You must be logged in to reply to this topic.