September 15, 2022 at 14:30 #40152
just downloaded and installed NoMachine 8 for Linux and after restarting the server I’m no longer able to re-connect to a physical desktop. Client and target machine both are SuSE Linux Enterprise 15 SP3. I can connect to the remote host when it shows the login mask. Then I login with my user and the desktop is created correctly. The I disconnect the nxplayer, and when I try to connect again to the same machine with the correct credentials for the user I’m stuck with “Waiting for the desktop user to authorize your connection”.
I explicitely set
in server.cfg but that doesn’t help (I guess it’s the default, although commented). Also note that when I change this to “administrator,owner” (which should be enough to reconnect with the same user) I will disconnected after a few seconds when logging in from the login mask.
Thus, it seems the user checking system is messed-up. It worked flawlessly with NoMachine 7.
FrankSeptember 15, 2022 at 16:42 #40156BilbotineKeymaster
Thank you for your feedback.
Can you please enable logs, reproduce and send us by email to forum[at]nomachine[dot]com, making sure to reference the topic in subject ?
Furthermore, can you show us these keys
PhysicalDesktopAccess PhysicalDesktopMode PhysicalDesktopAccessNoAcceptanceSeptember 15, 2022 at 17:14 #40157
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 🙂September 16, 2022 at 09:57 #40162sil04Keymaster
we just re-tested and all works as expected with the default configuration: user connects the first time, then reconnect the second time with system password and without the need to be authorized by the desktop owner since he’s the same user.
However, we would like to understand what caused the problem you experienced, as it could affect also other users.
1) Could it be that you changed some settings in v7 before the upgrade? Which ones?
2) Or did you change something in v8 before reconnecting?
About option ‘Don’t require acceptance if the user logged in as the owner of the desktop‘ in the UI (at the moment checked by default), it has been added because of a very common case, i.e. having only one system account on the remote machine with all users using the same account to login in a desktop sharing scenario.
For sake of clarity, we are evaluating to invert the logic of that option so that it must be checked in order to require desktop owner authorization also when the user logins with the same account.September 16, 2022 at 10:21 #40165
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.September 16, 2022 at 10:36 #40167sil04Keymaster
Quick update. We decided to leave the option as it is. It also “matches” the other option, also being a “Don’t” :-).
You must be logged in to reply to this topic.