Forum Replies Created
I will send them. In the meantime I detected another bug with SLE 15 SP4 that I can reliably reproduce: when using gnome as desktop (we don’t used gdm but kdm or sddm for login, I’m not sure if it’s related to that or not) it will start in a somewhat strange mode. It shows the “Activities” button and a search field and some icons at the bottom. But the background image is smaller and only when you click on it, it will maximize and show the usual desktop icons. I thinks that the workspace you must activate by this first click in gnome-session-41.3.
Anyway, in this initial state where the desktop is not yet clicked, NX will not even try to lock the screen when disconnecting. I tailed ~/.nx/nxserver.log and there appears no line at all when disconnecting, no matter how often I re- and disconnect. But as soon as I clock the background image and desktop appears and I disconnect, I will see messages about org.gnome.ScreenSaver and also my test script I quoted above will receive a signal again.
Do you want logs for that problem, too?
Not sure if the debugging was set accordingly for the logs in user home, but I can send them together with the global nxserver.log so that you can filter the matching logs from the users home. Where do I send them?
yes, we have added options to server.cfg for nomachine 7, and I found the culprit: We used “PhysicalDesktopAuthorization 1” which required a permission when users other than the owner tried to connect in NoMachine 7.
With NoMachine 8, this option requires permission for every user, even the owner, and to override this, you must explicitely state “PhysicalDesktopAccessNoAcceptance owner” (or even more users than just owner) or remove the PhysicalDesktopAuthorization option to make the commented defaults in server.cfg work as expected.
Thus, people having used “PhysicalDesktopAuthorization 1” before might run into this issue. I’m not sure if your update process removes this option in server.cfg, but in our system our settings for server.cfg are automatically re-added if they were lost, so even if the update process had removed it, it was re-added by our scripts.
We have now removed PhysicalDesktopAuthorization from our scripts as it seems not longer to be used in NoMachine 8 (at least it cannot be found in the default server.cfg).
So the problem was that PhysicalDesktopAuthorization obviously should no longer be used, but it still has effect if it is used in server.cfg. Assuming that most people don’t use scripts etc. to add options to server.cfg, this might not hit many people if the update process removes the option.
your request for the keys solved the problem. It is neccessary to set
PhysicalDesktopAccessNoAcceptance ownerat least, then I can reconnect (after restarting the server). PhysicalDesktopAccess and PhysicalDesktopMode can be left commented.
This seems a little strange for two reasons:
1) PhysicalDesktopAccess and PhysicalDesktopMode seem to default to the values that are commented out. But PhysicalDesktopAccessNoAcceptance does not, because it must uncommented to work. This seems confusing.
2) Why should the owner of the desktop be required to request a permission from him/herself? This is not possible because if I connect as the owner from remote, I won’t be sitting at the physical desk to answer my own request 😉 And as I have to enter my password anyway this seems like a superflous security constraint. Only if someone had stolen my password, but I would still get informed that someone has connected. I guess PhysicalDesktopAccessNoAcceptance should default to at least owner, otherwise many people might lock themselves out when updating the nomachine server while only working remotely (which is not unusual due to homeoffice at the moment).
Anyway, for me the problem is solved due to your hint to the according setting, so thank you very much 🙂
Yes, that was the reason. Sorry I missed that, but I wasn’t aware it would log in the home directory, so I missed the error messages there 🙂 and couldn’t google for it.
Thanks for your help!