November 18, 2020 at 06:03 #30424
Although the topic is marked as ‘Solved’ it is not solved
Having done all the config in previous posts I still get the error
BUT 6.11 does not have the issue 6.12 does. NoMachine have to know what they did. My Machine is headless so I cannot ‘accept’!
The whole issue of security is cute, but I want a way to totally disable a feature that has no relevance to me at all. (a ship in middle of ocean with no internet access)
Or NoMachine is not the product for me
JamesNovember 19, 2020 at 10:56 #30447
Which topic is marked as solved? I thought maybe a topic that you submitted previously but you haven’t submitted any topics prior to this one. Please provide a link so we can understand what issue you are referring to.
What Linux distro are you connecting to, what version? Is Wayland running there or Xorg? You say that on NoMachine version 6.11 you didn’t have this issue, have I understood correctly?November 19, 2020 at 16:08 #30449
I’m connecting to various including xubuntu 20.xx where I believe I must deal with wayland and SuSE 15.2 where I believe wayland is not an issue.
I downgraded and immediately connected. I tried to connect today and got the ‘waiting …’ message but I’m not certain of every detail so I’ll pedatically check.
JamesNovember 19, 2020 at 16:13 #30458
Additional details which are also asked in the other topic are require as well:
Which desktop environment and desktop manager are being used?
Is it a physical machine or a virtual?
Is Wayland being used for login window or/and desktop on the Xubuntu host?
And you confirm that uncommenting ‘WaylandEnable=false’ on /etc/gdm3/custom.conf didn’t work?
November 20, 2020 at 15:43 #30469
I’m not your typical user 🙂
Am dealing with a dozen or so machines, most amd64 some arch64.
Desktop is mostly xfce4, some lxde some lxqt.
50/50 mix of real machines and VMs. Most VMs are virtualbox, some are parallels.
40/40/20 ubuntu (20.04 and 20.10), openSuSE 15.2, Debian buster.
There is NO /etc/gdm* since gdm is not used.
SuSE does not use wayland
debian buster does not use wayland
Don’t know howto (or even if) xubuntu uses wayland.
JamesNovember 23, 2020 at 08:56 #30492
It seems strange that all those NoMachine servers are presenting the same problem. As Mth wrote in the topic that you mentioned, the default behaviour (and provided the configuration files have been messed with):
1. When there is Login Window, you can connect with any user without prompt.
2. When there is a user desktop logged (User A), you can attach as the same user without prompt. (To UserA’s desktop)
If you enter different credentials in NoMachine player (UserB), you are not desktop owner, there could be a potential security risk involved, so UserA will see the prompt and consequently decide whether to authorise or not.
Since we are not able to reproduce the problem, I suggest you increase the debug level in the logs of one of the affected host machines (let’s say from one of the x.org hosts) and send them to us and we will take a look. For now you can continue to run the earlier version of NoMachine. Instructions are here:
Enable debug on the server machine and then do:
sudo /etc/NX/nxserver --restart
Then please gather logs either manually or by executing:
sudo /etc/NX/nxserver --debug --collect
Please send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the mail’s subject.November 23, 2020 at 15:16 #30498
You explained so even this Bear of little brain understands perfectly. I can make it work for me, my customers would not be affected.
One of the issues I have been dealing with is auto-login not working. I’d be foolish to say ‘I never did THAT’ but the behaviour HAS changed. So what!
I’m more than happy to make debug logs if they will assist you, but it appears that NoMachine is working as intended. If the logs will help then please say, else thanks for the help.
PS a comment: If userA knows userB exists and userB’s password then how is userA logging into userB’s session a securety risk?
What can you do in a NoMachine session that you could not do with ssh?November 23, 2020 at 17:49 #30504
It’s not clear to me what the problem was that you were encountering in the first place, but if you considered the “issue” resolved, that’s fine. I requested logs because I was under the impression that you were seeing a “waiting for desktop to authorise” message despite 1) logging in with the same username and 2) you had followed the advice of Mth in the topic you mentioned.
I mentioned “security risk” which is taken from Mth’s original answer to the topic that you were quoted at the start of this thread: having an unwanted user attach to your desktop without your permission is not what most people want. So the desktop owner has a choice to accept or refuse. Of course, if you trust the user with your username and password (you are the owner), then that’s entirely your choice and not under discussion here.
Maybe you should have a look at the Security section of the Server Guide document in our Knowledge Base.
If you continue to see behaviour which doesn’t match what you’ve set on each server, please open a new topic: https://www.nomachine.com/DT10O00155#2.2.
You must be logged in to reply to this topic.