Forum Replies Created
may you please tell us also which is the driver version of graphic card on the client?
Quick update. We decided to leave the option as it is. It also “matches” the other option, also being a “Don’t” :-).
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.
> Is there a way (besides out of band software management) to make it auto install?
No, there isn’t. By design updates can be downloaded in background (it’s option “Download updates in background” in Updates panel in the UI) but they will be not installed automatically. User will have to start manually the update process.
To avoid pop-up messages you could disable ‘Automatically check for updates ‘ in the Updates panel and run ‘Check now’ at your own convenience.
thank you for confirming that you had the pointer highlight enabled. This case is described here:
How to send Control key to the remote desktop when the user has the pointer highlight enabled
A hint for finding relevant information in our Knowledge Base (https://www.nomachine.com/knowledge-base) is to provide a keyword and restrict results to the area of interest (e.g. articles, trouble reports or feature requests).
by design NoMachine – in order to avoid to interfere with the Window Manager – relies on a ‘passive grab’ way: i.e. it intercepts the key press only when there is not an active grab. When the session is running at full screen, the client is for sure the only active application and it uses the ‘active grab’ way.
This approach has been suitable for almost all situations, until now we are aware of a unique case in which it can be helpful to force always the active grab. This is when the pointer highlight is enabled: https://www.nomachine.com/AR01P00959.
The possibility to launch the client with the –activegrab option has been added to solve exactly this case.
May you please tell us if you have the pointer highlight enabled too?
Hello Lloyd Andrew,
the first reply to this topic seems to have misinterpreted your initial question.
Let me clarify differences between ‘Stop the server’ and ‘Shutdown the server’ and how manual/automatic startup of services is intended to work (I will adopt naming convention used in v. 6).
‘Stop the server’ means that NoMachine server will not accept incoming new connections to your computer.
If there’s already a connection, it remains active. All NoMachine services remain also running.
‘Shutdown the server’ means to terminate all NoMachine services. So, if you shutdown the server you should not find any active NoMachine service among your Windows services.
When you choose to shutdown the server, you will be requested if you want to automatically start NoMachine (server and all services) at next reboot or not.
About the NoMachine Network services panel in the GUI and your comment:
> NoMachine Network services shows the host server status as “Stopped”
This panel shows the status of nxd, the NoMachine network daemon (NX) in charge to accept connections to this host on default port 4000. This service can be stopped and restarted and also configured for manual/automatic start at boot via this panel. Such settings apply only to this service, not to all NoMachine processes.
As a further note, the previous replies point to a couple of articles which explain more in detail how to shutdown NoMachine (server and all services) and set the manual start mode at reboot. There are alternative ways to do that.
Thanks for the detailed description.
We opened a new Feature Request which should address your needs:
Extending the ‘nxplayer –session’ command to always create a new session
We are also planning to allow administrators to configure the server for always starting a new session at every connection of a given user.
Did you have the opportunity to evaluate guest sessions (automatic generation of guest sessions) as suggested by Tor?
We would like to know if using guests is suitable for your requirements and if not, why.
Another possibility would be to configure the server for always creating a new session. This applies only if the session must be terminated and there’s no need to reconnect it. Please confirm if the session should be terminated when it’s closed or suspend/reconnect abilities are necessary.
We are also evaluating pro and cons of adding a further option to the ‘nxplayer –session’ command to allow to specify to run ‘this’ session on ‘this’ node. This option should be used in conjunction with a further option which forces the creation of a new session. In most cases however, it should be possible to reach the same result by means of tuning the configuration.
Please let us know if any of the suggestions above fit your scenario.
On Linux you can access NoMachine server settings by entering root credentials or credentials of a user with sudo privileges.
To grant sudo privileges to your user, you must add it to the sudoers group.
Commands for giving sudo privileges to user can be different, so you should check the official documentation for your Linux distribution.
Please note also that in the current implementation it’s not possible to enable changes in server settings GUI on machines with versions of sudo prior to 1.7.4. Authentication as root should work instead.
root user or a privileged system account.
As you probably know, there are many ARM variations and many Linux versions for each variation, requiring different tweaks to get a build working at acceptable speed. Unfortunately at the moment there is no way we can produce builds for every possible processor and configuration.
only users with administrative privileges can change server settings.
these “debug version of NX”, are custom builds we prepare on purpose with debug symbols and logs enabled in the components we suspect may have generated the problem. We can’t distribute these versions as standard because they would be really huge and because a component with logs enabled, depending on the component, may generate megabytes of logs per second. In the best case it would fill your disk or slow the machine to a crawl.