Forum Replies Created
-
Posts
-
We went through our article and checked our configurations with what you posted. Bear in mind that the instructions in the article are for one type of many possible configurations. For your set up, this should work:
edit /etc/pam.d/nx like here:
# This is a default PAM configuration for NoMachine. It is based on
# system’s ‘su’ configuration and can be adjusted freely according
# to administrative needs on the system.auth [success=1 default=ignore] pam_unix.so nullok
auth requisite pam_deny.so
auth required pam_permit.so
auth required pam_ecryptfs.so unwrap
auth optional pam_cap.soauth required pam_google_authenticator.so
account include su
password include su
session include suWe’ve tested it and it works.
Are you using macOS and cycling through the monitors? ‘3’ is used for the third monitor in the case you have one. And ‘all’ already exists, just use ‘A’.
https://www.nomachine.com/switching-the-view-between-multi-monitors-during-a-remote-desktop-session
No problem 🙂 We’re investigating further. Generally those instructions are good to go for most Linux systems. Can you confirm you are using the latest Linux Mint? What Windows version are you connecting from? In the meantime, are you able to send us the logs? You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243. Send both server-side logs (from the Linux Mint server) and the client-side logs from the device you are connecting from.
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
It’s possible that you need to adjust macOS permissions. It’s possible that you didn’t agree to something by accident. Check the article here and make sure that NoMachine is allowed to record and process audio on macOS. If NoMachine is present already, remove and re-add.
https://kb.nomachine.com/AR11Q01061
Does that help?
Can you send us the server-side logs. Enable debug and extract them using the instructions here: https://kb.nomachine.com/DT07S00243. The command ‘
nxserver --debug --enable‘ allows to gather debug logs for all components: nxserver, nxnode, nxwebplayer/runner and the display agent. Execute it on the server/node machine where the problem occurs. Please don’t remove the node logs as they are important as well.Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
We understand your requirements and we’ve been planning to add this capability in NoMachine. Until then it could be possible to use a third party tool like Ansible. We have created a Playbook which works in our environment and does what you are requesting. Please reach out to us directly for further instructions if you are interested.
As for the question about the user’s home. The .nx folder is created in the user’s home directory when they start a session. However, you say that some users don’t have one. Are you using Active Directory? A known issue with AD is that the home is missing until the AD user logs-in to the machine, independently from NoMachine. This could your case.
AD mobile accounts cannot create sessions on the remote host at the first login if they cannot access their home
https://kb.nomachine.com/TR04R09659And disabling HW decoding on the Ubuntu client side when connecting to the Ubuntu server changes nothing? Send us the logs as from both sides as per the instructions here, thanks: https://kb.nomachine.com/DT07S00243
Hi, thanks for following up and we’re pleased to know that the issue is now resolved. Would you be willing to provide logs for us to check? It would mean re-enabling HW encoding on the server (temporarily of course), reproducing the problem and then gathering up the logs from the server machine. If you’re interested,you can extract them using the instructions here: https://kb.nomachine.com/DT07S00243
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
Thanks for confirming. Just to clarify, NoMachine tries to restore the last state saved when the connection was closed. However, there might be conditions preventing that from happening, such as a monitor which is now no longer available. In that case the state is restored to the default conditions.
Can you tell us:
– the Ubuntu version and desktop environment?
– whether the Ubuntu client isusing multiple monitors? If yes, what is the monitors’ layout? Does the client always start on the same monitor?
– the output of command xrandr –listmonitors launched in a terminal window?Hi,
I’ve not setup anything to use google-authenticator in NoMachine it just automatically uses it as soon as the .google_authenticator file is present in the Linux users home directory.
Indeed, NoMachine does not need any configuration, but you will need to make some changes to the PAM configuration. There is an article in the knowledge base that explains how to set up Google Authenticator with NoMachine https://kb.nomachine.com/AR12L00828#3.2. I’ve linked you to the section dedicated to Google Authenticator directly, but it’s worth reading the earlier sections 1 and 2.
Does that help?
Sending each monitor separately, giving priority to the monitor in use, it’s definitely something we have wanted to do for a long time, but there have always been other more important things to take care of. People are still actively working on this. HEVC/265 is a complicated matter. The way we go is to always privilege the HW encoding and decoding available on the target machines, also because of the licensing charges, in the case we would have to deliver also the codecs. We have extensively experimented with HEVC/265, but the problem is that it must be supported on the HW on both sides, client and server, and such lucky configurations are rare at the moment. Also consider that SW encoding is less performant than HW encoding.
I’m not sure I understand the question LOL You want to want know why the connection was not stuttering with NoMachine’s HW decoding in its default setting (i.e Enabled)? It’s meant to work that way 🙂 What we don’t know is why the stuttering suddenly stopped and started again.
But we now know that disabling HW decoding has removed the stuttering, we can say that it’s most likely a problem with your video card and/or driver, so there’s no further investigation required.
A quick update on this topic. We have opened a Trouble Report:
The LD_PRELOAD variable is set in the environment of all applications running in a KDE Plasma desktop
https://kb.nomachine.com/TR02W11273and we invite users to track its status using the link. As Fra81 wrote, we’ve only been able to reproduce this problem in our labs when running the ‘ping’ command with KDE Plasma running on X11, and not Wayland. Investigations will continue and if we have any updates on the investigation, they will be posted here. The topic, however, will be closed. A new topic can be opened, if necessary, as a continuation of this thread.
It sounds like an issue with your system set-up or even network. Please update to NoMachine 8.16. If you are still experiencing stuttering, disable HW decoding. When you are connected to the desktop with NoMachine, open the menu (Ctrl-Alt-0) > Display > Change settings > Options, button Modify (https://kb.nomachine.com/DT09T00267#5.8), click the box next to ‘Disable client side hardware decoding’. Does that make any difference?
As we wrote, Sway is not fully supported yet and for this reason EGL libraries won’t work. DRM can work as a fallback but it has limitations, for example with virtual machines and proprietary drivers. In your logs we can see such typical errors, but you did not confirm whether the graphics drivers are indeed proprietary or open source and whether you are running the Ubuntu system in a VM. This would be useful for us to know.