Forum Replies Created
-
Posts
-
Hello tom5 and mw32, please check for emails from our forums which include links to a patched package.
Hi, we close topics after a couple of months when there is no more input from the author or any other user. Thanks for providing this input 🙂
Is it possible that with the outage some hardware damage has occurred? It’s hard to say what is wrong without checking the logs for error messages from the server side and affected node.What you pasted is not enough information. Follow this link for instructions https://www.nomachine.com/DT10O00163#1 and submit them to forum[at]nomachine[dot]com. With three nodes (in loadbalancing via Enterprise Terminal Server?) is it possible you have a support subscription? In that case, you should open a support enquiry with all the details.
This is a race condition due to network speed and server load. Closing the connection and trying to connect, even multiple times, can sometimes help.
NoMachine client never stops showing the spinning wheel when connecting to a server
https://www.nomachine.com/TR05R09688If you need a quick fix, try setting the
ClientMenuConfigurationkey in the server.cfg on the server to the default value, i.e. comment it out:#ClientMenuConfiguration allSuch a change doesn’t require a restart of NoMachine server
Does the fix help?
Installing NX and logging in with system credentials works out of the box. Changing the cfg files original settings should be done provided you understand what you are changing and why.
In its default installation EnablePasswordDB in the server.cfg is set to ‘0’ which means we do not use our password db, but use the system authentication method.
You edited the server.cfg using Windows tools, and in doing so (for which we have opened the following feature request by the way https://www.nomachine.com/FR05R03981) nxserver lost its ability to read the server.cfg properly and so NX password db became enabled and you user could no longer login using system credentials.
Something good came out of it. We discovered that Windows editors misbehave when editing unix files, so we will improve the software to make sure this doesn’t happen 🙂
Is there a logic to that? That NoMachine has a problem with headless machines? Also if I add a GPU to my system instead of using an onboard (i)GPU, would the GPU still do the work without a monitor or TV connected? Or the TV on standby? Or is that the X-server thing you’re talking about?
No, NoMachine doesn’t have a a problem with headless machines. The logic is rather simple: if there is no monitor attached, the GPU can’t function. It’s not NoMachine that isn’t working. You can consider purchasing a dummy dongle. This will make your system think there is a monitor attached and the GPU will function correctly. Then NoMachine will use HW encoding. Search these forums for the word “dummy dongle” and you will see other users who did the same.
Send the refused file via email to the address I indicated in my earlier reply, thank you. At this point I would also send us the full set of logs. To extract logs, see the following article, https://www.nomachine.com/AR10K00697.
We need them from both the server side and the client side (the computer you are connecting to, not only from the computer you are connecting from).
Can you tell me what message you are getting when trying to connect to your Windows machine? Are you able to connect the other way round, from the Windows computer to your Linux computer?
Hi, are you able to send us the logs from the server side? You should enable debug, reproduce the problem and then extract the logs. See here for details on how to do that: https://www.nomachine.com/DT10O00163#1
Send your attachments to forum[at]nomachine[dot]com making sure you insert the title of your topic the email. Thanks!
Hi, thanks for taking the time to report this. There was a hitch with the manifest in the update server, but it has since been fixed 🙂 See these two topics for reference:
https://forums.nomachine.com/topic/session-negotiation-has-failed
https://forums.nomachine.com/topic/session-negotiation-failed-running-db
I don’t know which topic you are referring to but there are two similar ones open here:
https://forums.nomachine.com/topic/green-screen-after-updating-to-6-10-12-2
https://forums.nomachine.com/topic/green-screen-after-updating-to-6-10-12Please follow either of those links for the Trouble Report.
The config files are clean and the logs don’t show anything wrong with NX. The optimizations NoMachine can offer are within the session itself, not before webplayer has been fully loaded.
The following Trouble Report has been opened:
Green screen when connecting by NoMachine client for Windows v. 6.10.12 to Ultra HD monitors
https://www.nomachine.com/TR05R09689For everyone affected by the “green screen” issue please consult the Trouble Report we opened which contains further details:
Green screen when connecting by NoMachine client for Windows v. 6.10.12 to Ultra HD monitors
https://www.nomachine.com/TR05R09689If User A connects, and then another user WITH the same account connects, the session will migrate. NoMachine understands that the owner is connecting from another client and thinks it’s the same person.
Is it not possible for you to allocate an an individual system account to the users which need to connect? The default behaviour is that if UserA is connected to the remote computer, and UserB tries to connect, UserA will see a pop-up notifying them of the attempt. Only if UserA ignores the notification, they will be bounced off.
Tom5, can you send us the user/.nx from your Windows Enterprise Client? Then from the Cloud Server host, send us the var/log. Instructions are here: https://www.nomachine.com/AR10K00697.
Then send everything to forum[at]nomachine[dot]com. Make sure you place the title of the topic in the subject. Thanks!