Forum Replies Created
-
Posts
-
We are still unable to reproduce. One thing it might be is the autorepeat function on Ubuntu. It’s one of the known limitations listed here in our notes about connecting to physical displays running Wayland: https://kb.nomachine.com/AR02P00969.
To disable autorepeat on Ubuntu 24, you can adjust the keyboard repeat settings in the Accessibility settings. Open the Activities overview, search for “Accessibility”, and click on it. Then, select “Typing” and find the “Repeat Keys” section. You can either switch it off entirely or adjust the “Delay” and “Speed” sliders to customize the autorepeat behaviour. It’s worth a try.
It would also be useful to know if you get the same identical problem when connecting from a different OS. If possible, install NoMachine on a completely different OS and start a new connection to the same Ubuntu server.
Sorry for the late reply.
So… where does it “take its cue” for which resolution(s) to offer up on that “Virtual Display”? Presumably if you connect from a NoMachine Client that is a single screen laptop with 3200×1800 resolution, then its going to make a “Virtual Display” (on the alix2d3 board with no GPU) that matches your laptops resolution?
Yes, the initial resolution of the virtual desktop depends on the monitor resolution on the client, but can be changed later depending on the configurations in the session menu.
But what if you want two screens on the remote side? and to choose their resolutions?
You can’t arbitrarily select the number of virtual monitors, but you can have as many virtual monitors as there are monitors on the client, as long as you use the “Resize remote display” mode and then go “Fullscreen on all monitors” (https://kb.nomachine.com/AR06U01201)
It’s most likely a problem with your system, and not with NoMachine. If you’re having issues with port-forwarding and display, opening a separate topic is best 😉
What you sent us is from the player side.
192 192 2025-07-12 18:56:21 028.117 ClientSession: Failing reason is ‘No route to the network or to the host ‘172.xx.x.xxx’ was found. The issue could either be caused by a wrong server address or by a networking problem. Please verify your connection and try again.’.
On the server host you want to connect to (172.xx.x.xxx), go to the settings>server>security and set debug level 9, restart, reproduce and click take logs.
Please update to NoMachine 9, since the TR I linked in my previous post is now solved. If you still encounter the problem on v9, a new topic can be submitted. Thanks!
Can we see the logs from the server side machine? Go to Settings > Server > Security, set log level to 9, reproduce the problem, then “take logs “. For full instructions see this document: https://kb.nomachine.com/DT08U00298. Send us the complete file, you can either attach here or send directly to forum[at]nomachine[dot]com, making sure to reference the title of the topic as the subject of your email.
“I don’t even know what “an MDNS connection is” – Sorry, I was asking how you are connecting, i.e are you creating a connection or are you clicking the machine icon (pipe icon) to connect.
In any case, we still need logs with debug enabled on the server because the problem you have now is different to the original “connection reset” error. Please send the server logs and the player logs as described in the document I linked previously.
What is the best practice to add nodes created in inverse mode to nodes group “ndgr_XYZ” ?
The best practice is to use node commands on machine with installed CS
This local admin can’t create nodes group on ECS, managed by a dedicated admin, can he ?
The admin who is managing nodes of ECS cannot manage ECS groups.
Should only these 2 commands be used by ECS admin to addd nodes to nodes group ?
Yes
It is mandatory to use node_UUID ?
You can choose between uuid and node-name. When you manage nodes which are accessible from ECS you can also use ip:port. In your case nodes are behind firewall so you can only use uuid/node-name.
Hi mckaygerhard, we checked the code fragment he proposed, but there wasn’t any change. Can we ask you to submit logs? In Settings > Server > Security, set log level to 9 and restart the server. Reproduce the issue and then go back to the settings and click Take logs. Submit the file here or send directly to forum[at]nomachine[dot]com. Thanks!
We have opened a Trouble Report which you can monitor here: https://kb.nomachine.com/TR07W11459. Although your issue is a black screen, it’s caused by the same bug.
Your request is certainly a reasonable one though, so we’ll see how we can improve this aspect
Please use the following link to monitor the fix: https://kb.nomachine.com/TR07W11471.
We have opened a Trouble Report for this issue, please use the following link to monitor its status: https://kb.nomachine.com/TR07W11470.
You say it’s on the same LAN, so are you using an MDNS connection (a NoMachine host broadcast on LAN) ?
Can we see the logs from the Raspberry server? Go to Settings > Server > Security, set log level to 9, reproduce the problem, then “take logs “. For full instructions see this document: https://kb.nomachine.com/DT08U00298. Send us the complete file, you can either attach here or send directly to forum[at]nomachine[dot]com, making sure to reference the title of the topic as the subject of your email.
This is the Trouble Report which you can monitor: https://kb.nomachine.com/TR05W11324.