Forum Replies Created
-
Posts
-
1. I don’t like the idea to provide admin credentials to a unknown application.
NoMachine asks for credentials in order to execute operations (update in this case) which require admin privileges, the same ones that are required for when you install. These credentials are used ONLY for executing the authentication being requested by the system and there are not saved in any way, not even temporarily. You can also skip automatic updates and update with downloading the latest version directly in the terminal, but you would still need to pass the admin password in the terminal.
2. I now did setup a VM (openSuse, KDE) for a test, entered credentials, and finally nothing happened
Do you mean that after the dialog requesting admin credentials to allow the system to update, nothing else appears?
3. so again the question: what should happen ?
We integrate with the system to access its authentication layer and use its graphical interfaces, but sometimes a configuration or a distribution property could require to show the authentication dialog within the NoMachine software update window. In this example of what you should see we’re updating NoMachine on Ubuntu (see attached images). You’ll notice a different dialog asking for password, due to the system integration explained above. You could install ‘zenity’ and see the same sequence of dialogs.
4. do you plan to provide signed RPMs in the future ?
It’s not in our plans at this time.
5. do you plan to provide YUM repos for RPM based distributions ?
It’s not in our plans at this time.
If the patched package solves the problem and the connection problems you were experiencing are no longer there (I doubt these were caused by the package), then logs are no longer necessary.
Regarding the screen blanking on Wayland, D-Bus and PipeWire must be present and properly working on the system. You should follow the tips and instructions here:
Notes for connections to Linux physical desktops running Wayland
https://knowledgebase.nomachine.com/AR02P00969Please use this link to track the progress of this bug report:
Client ignores the local cursor theme
https://knowledgebase.nomachine.com/TR02T10472We were unable to reproduce this issue. If you encounter the problem again, we will need client and server side logs.
We noticed that the permissions of /proc/net/unix are set to 400. Default on Debian 10 is 444 – did you change this by yourself or can you determine if it has been changed by some application which you are using?
Setting again permissions to 444 should fix the problem.
This looks like a permissions problem. What desktop environment is this, I can’t tell from the screenshot? Check permissions and ownership of the home directory, $HOME/Documents/NoMachine and $HOME/.nx folders.
I also have to close all 4 or 5 of the initial setup windows
This could be helpful:
https://knowledgebase.nomachine.com/DT11R00186, chapter 2.3It could be a permissions problem because logs show NoMachine doesn’t have access. What’s the output of
ls -l /proc/net/unix? Are you connecting to a physical Linux machine or is it a virtualized machine of some kind?Renaming is not only a modification to the software which would not be allowed by NoMachine’s EULA, it could also break your installation.
Send the Linux logs over so we can check. The ones you got from the Windows client didn’t attach, so send them on as well.
On the server side what’s the output of
/etc/NX/nxserver --statusin a terminal? If it’s not “started”, can you restart it with--restart? Logs would be useful if restarting doesn’t help. For logs please check this article https://knowledgebase.nomachine.com/AR07K00677 . You can send them directly to forum[at]nomachine[dot]com. Please use the title of the topic in the subject of your email 🙂It could be that port 4000 is already taken. The Network Server (nxd) listens by default on port 4000. If you have another application using port 4000, you can change it for NoMachine in server.cfg.
More about default ports that NoMachine uses is here:
https://knowledgebase.nomachine.com/AR01L00770How to solve port conflicts with other applications
https://knowledgebase.nomachine.com/AR11L00823Here I can see in the log excerpt that you are using an nx derivative which could be interfering with NoMachine. Uninstall it and then try using NoMachine. If you reproduce the same issue, we can continue this thread, with fresh logs being submitted.
Update: user confirmed that on the remote host there is no NoMachine package installed. This topic is therefore closed.
Further reference:
Supporting earlier versions of NoMachine and NX
https://knowledgebase.nomachine.com/AR07O00933Restarting the nxserver would mean you lose the logs. You would need to reproduce the problem again, and send in a new set.
