December 22, 2020 at 13:24 #30848
Recently (auto)upgraded several Windows10 machines from 6.x to 7.0.209 and cannot connect to at least two of them (one in LAN, one is remote over SSH tunnel). In both cases symptoms are the same: “Error is 108: connection reset by peer”. At the same time it appears that NoMachine service is being constantly restarted on target machines – when connecting it usually shows “no display” then changes to “physical display” and cycles between the two. And logs are also showing errors and restarts. At the same time can connect to Ubuntu machines that have undergone same upgrade without any problems. Logs from one of “affected” machines are attached, not [really] informative for me.
Attachments:December 23, 2020 at 15:43 #30893HavenContributor
It looks like we cannot start ‘nxclient –monitor’ process:
13644 13644 2020-12-22 14:35:45 946.970 NXNODE WARNING! Process ‘C:\Program Files (x86)\NoMachine\bin\nxexec.exe –monitor –pid 1028’ with pid ‘13824/936’ finished with exit code 1 after 0,051 seconds.
Due to that problem we cannot make physical desktop available.
Could you please provide directory ‘.nx’ from home directory of current logged user?December 24, 2020 at 10:41 #30915
There are a lot (2295) of directories there majority of which (I assume) relate to particular sesssion, thus I copied most recent five of them and all dirs/files which seem to belong to NX itself.
I can see some strange account name in “session” files – such account definitely does not exist.
Attachments:December 24, 2020 at 13:18 #30929
It persists with 7.0.211December 25, 2020 at 21:08 #30948GegaParticipant
Does NoMachine start normally if you log in with a different user?December 30, 2020 at 08:52 #31025
Sorry, I probably don’t understand the question
NX runs as a service regardless of logged in user, i.e. I can [used to be able to] connect to machine that just started up and waits for username/password. Moreover, same behavior is witnessed on two machines – one is [let’s call it] shared desktop with multiple users, another one is configured with single user, but is also password protected.December 30, 2020 at 13:20 #31031HavenContributor
Thank you for taking the time to report this.
We reproduced the issue in our labs. Here is the relevant Trouble Report:
Please use the “Notify me” to know when a fix is available.December 31, 2020 at 09:02 #31041
To clarify a bit – in all cases I used Latin-only for account names on system set up and then after first login linked those up to MS account. Maybe this information will help a bit. No non-Latin characters are used in account names. So it came as a surprise to see weird (=non-Latin) characters in log files.December 31, 2020 at 12:24 #31066BritgirlKeymaster
I think here the issue is internal Windows system account not common system accounts (local usernames). We can provide a patched component for you to try if you’re interested. Please check for emails from us for the download link 🙂February 22, 2021 at 09:53 #32079BritgirlKeymaster
The patch was made available in the release of version 7.1.3.
You must be logged in to reply to this topic.