Forum Replies Created
-
Posts
-
Hi, can you try 8.13 which we just released? Our codec devs added some improvements for the loading of libvpl to avoid this problem.
We don’t know how much of the Wayland protocol is used by KDE internally or in the communication with the other apps, but we do know that the communication with our agent uses the X11 protocol š The resize issue, to be honest, doesn’t look like a NoMachine bug.
Hi,
Have you tried running the script from node.cfg? Node.cfg is executed as the running user you could try that. Custom scripts set-up in server.cfg are common to all the users who are accessing the server and are executed by the nxserver program.
There is a Trouble Report open which may affect the outcome https://kb.nomachine.com/TR03V11117. If that doesn’t help, then you could try using one of the terminal server products and run virtual desktops for each of your users, disabling the screensaver for the specific user maybe? NoMachine Workstation, available as evaluation software, provides 4 virtual Linux desktops, each one separate, for User A, B, C and D.
We checked the logs and they are clean. NoMachine handles the resize correctly but then the desktop fails to adapt. You mentioned that you have this problem with startplasma-wayland, but not with startplasma-x11. Even when running the Wayland command, the virtual desktop will fall back to using X11 in any case, because that is the only protocol that NoMachine virtual desktops support at the moment. So the recommended command is startplasma-x11.
Thanks for the additional info. I confused https://kb.nomachine.com/TR05V11141 with https://kb.nomachine.com/TR04V11131 (The latter was fixed in the latest update). Our developers are currently working on the somewhat complicated KDE issue (TR05V11141), but we are unable to promise a fix in the next maintenance release.
NIPIAN, try the following:
1) disable HW decoding on the machine you are connecting from (instructions here: https://kb.nomachine.com/AR07U01202)
Does that make any difference?
2) If it doesn’t help, disable HW encoding on the machine you are connecting to. ( Go to server settings -> server performance -> uncheck āUse hardware encodingā).
Does that make any difference?
Please see my reply on a similar post:
Sorry for any confusion. I mistakingly inserted in to the old topic that TR05V11141 had been fixed.
Your previous topic highlighted the following TRs:
Attaching to the physical desktop could fail on Rocky Linux 8 with Wayland
https://kb.nomachine.com/TR03U10784 andCapture of the Wayland desktop by EGL doesn’t work with KDE Plasma 6
https://kb.nomachine.com/TR05V11141These are not fixed yet.
Hi Mitchell,
can you tell us what version of the Windows OS is installed on the server side?
To access any desktop via NoMachine you need a system account on that computer. You can use the local username assigned to your account on the Windows machine. To check the local username, just go into your C: drive, select Users and check what your local username is. Are you sure you are using the right password? If there is Win 11 on that machine, donāt use the PIN that Windows 11 asks you when unlocking the screen.
Some more tips about acceptable usernames and formats are available in the knowledge base article here:
https://kb.nomachine.com/AR03S01118If that doesn’t help, please send us logs from the both sides. You can do this by following the instructions here: https://kb.nomachine.com/DT07S00243. You can zip them up and send to forum[at]nomachine[dot]com.
Yes, it’s possible, in version 8, and version 7, by using the “EnableUserDB 1” key in the server.cfg file of the host you are connecting to. Before I explain how to do it, I want to mention first what is coming with NoMachine 9 which you might be interested in. NoMachine Network, which will remove the need to know the remote computer’s IP address and simplify connecting over the Internet (so no port-forwarding required), will allow you to configure which users can access the remote host, so what you call a “whitelist”. It’s a very straightforward way for users to limit access to specific users who connect using NoMachine Network.
Connecting to a remote host using its IP, the following method of enabling and restricting access remains as explained below.
All commands and edits to the server.cfg file must be executed with administrator privileges. Ensure you open your Command Prompt or PowerShell as an administrator when performing these actions.
1. Enable User Database
On the remote Windows where NoMachine is installed, edit server.cfg and set the following parameter:
EnableUserDB 12. Add Users to the “whitelist”
To enable access for specific users, use the following command:
%ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --useradd3. Verify Allowed Users
To check the list of users who have been granted access, run the following command:
%ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --userlist4. Disable Access for a User
To disable access for an existing user, execute the following command:
%ALLUSERSPROFILE%\NoMachine\nxserver\nxserver.exe --userdisableWe will improve our KB with an appropriate FAQ which targets free edition users. For the moment you can read more about this in any of the Enterprise guides: https://kb.nomachine.com/DT10R00171.
Hi, can you contact us via the Contact Us link in the footer and we will pass you a link to download the NoMachine package for macOS.
Hi, this time we need to see the debug logs. Are you able to send us the server-side logs with debug enabled so we can check them? Full instructions are 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!