Forum Replies Created
-
Posts
-
This is an LDAP issue related to some mis-configuration which we were unable to pinpoint. We were not able to reproduce this issue even with the user’s same configuration.
In a working and correctly configured environment, LDAP and local users have separate home folders location. Home directories for LDAP users are mounted dynamically using autofs from an NFS share. Based on the logs provided, there is a problem with create file ‘options’ and setting ownership for it in the case of LDAP users (so those who have mounted homedir during login to system).
After considerable investigation, the workaround proposed in this case is to set the following key in the node configuration file to point to a local directory instead of the remotely mounted one: UsersDirectoryPath /some/local/path.
On ECS V8.16, when nxDB is modified and by who ?
We store there almost all data added by the administrator (such as nodes and rules), as well as data created when new sessions or connections are established. There is also some data related to this instance’s installation, such as a unique UUID
Are all the modifications under control of an human (administrator) or some modifications are done by internal processes ?
Some of the data is added by the administrator, while other data is generated while the server is running
We’d like to know if it’s possible, for a cluster of 2 ECS (not ECSC) to keep their nxDB synchronized just by running twice the admin commands (add node, add group of nodes, …).
Two ECS servers work as two separate machines, whereas a V8 cluster is designed to keep the host always available using active-passive heartbeat mechanics. We do not synchronize databases between the two CS servers, but they can have the same nodes added to them.
Hi, thanks for the detailed report. This looks like a known issue. https://kb.nomachine.com/TR05V11141, specifically with KDE 6 onwards. What KDE version is it?
Hi, testing on the fly with default settings (out-of-the-box) we were not able to reproduce.
Can you send us the logs from the server host? You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243.
We’d also need any backtrace which you can extract following the steps here: https://kb.nomachine.com/AR09L00810
Send everything to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
The macOS packages are suitable for both Intel and M1 architectures. You can downloaded the package you need from this link: https://downloads.nomachine.com/download/?id=46.
The NoMachine for ARM/Enterprise Desktop for ARM packages are RPM and DEB, so suitable for Linux devices such as the Jetson Nvidia.
Hi, did you already try restarting the nxserver from the server settings on the Ubuntu host?
Is Ubuntu running on a physical machine or is in a virtual machine? Is the display server X org or Wayland?
Are you able to send us the server-side logs so we can check them? You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243. Please enable debug as explained in the instructions, then try restarting the server and extract the logs.
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
Support for authentication with smart card has been set-up by relying on the Public Key Infrastructure (PKI) and using an OpenSC compatible smart card, and using the SSH key method (see more about this here: https://kb.nomachine.com/DT07S00230#4, there is also a nice comparison table in chapter 2 which shows you what is supported).
The alternative is to use password authentication. However, we currently have a TR open related to USB forwarding and the remote desktop which shows the login window.
In the meantime we have tried to reproduce, without success, so it’s possible that the keys you are using are corrupt in some way, that’s why it would be useful for us to receive them, so we can also test them.
I did mention we use GNOME in my first message.
Yes, you are right!
About the firewall, when installing NoMachine, it creates rules for the nomachine service, without these nomachine would be blocked.
Which every software update seems to overwrite back to defaults,
I’m not sure what you mean. When installing an update, your previous configuration should be maintained. If something is being overwritten, it definitely deserves a new topic as you wrote 🙂
Hi,
Let me clarify. Each subscription is for the computer you want to access (the “server”) where the specific package for that OS is already installed, and the subscription is for the specific operating system i.e macOS, Windows or Linux. This means you cannot use a subscription purchased for macOS, let’s say, to activate Enterprise Desktop installed on Windows.
If you have a mix of macOS and Windows computers which your users must remotely access, each of those servers needs its own subscription for that specific OS. So a simple example: there are 5 Macs and 5 Windows server computers which users must connect to. You will need 5 x Enterprise Desktop for macOS and 5 x Enterprise Enterprise Desktop for Windows. Are you looking to purchase Enterprise Desktop Pack? Indeed it’s not possible to mix platforms when purchasing a pack. (But please contact our sales team which will be happy to help).
Instead, on the computers or devices that your users connect from (“clients”), you can install the Enterprise Client package or the mobile app. Clients are free and you can have as many as you like on whichever OS you prefer. Simply install the package for the specific OS.
Hi, take a look at the response I provided for https://forum.nomachine.com/topic/can-connect-but-screen-frozen#post-52625. The set-up is similar to yours. Does that help?
Another way to get round this limitation of the video card is to install an HDMI dongle (refer to the article) to force the system to take full advantage of the GPU as if a real monitor were connected. 🙂
Katpan was right about the version in which we added the option to allow the host identity key to be automatically accepted (see the link above), “Adding a new option in the UI to automatically accept the host identity key”.
There is now an option in the ‘Edit connection’ panel to automatically accept the new host identity key when the “Verify host identification” dialog is issued. If you go in to the Edit panel when configuring the connection, you can see the checkbox ‘Always accept the host verification key provided by the remote host’.
It corresponds to the following setting in the connection file (.nxs):
option key="Automatically accept new hosts identification key" value="true"