Forum Replies Created
-
Posts
-
That behaviour is directly related to the Docker Desktop application. It was created to work on physical desktop. When you create a virtual desktop and start Docker Desktop it will start on the physical desktop. The same behavior appears on vnc and rdp sessions as far as we are aware.
Can you first try disabling hardware encoding on the server-side? Go to server settings -> server performance -> uncheck “Use hardware encoding”, then connect.
If that doesn’t help, try disabling HW decoding on the client side and then connect. To do that, open the NoMachine menu panel inside the session by Ctrl+Alt+0 or click on the page peel at the top right corner of the window. Then click on Display -> Change settings. In that panel click on the Modify button to open the advanced display settings. Click on ‘Disable client side hardware decoding’ to disable it.
Do either of those help?
Please update to the latest version, NoMachine 9 includes the fix.
Here is the link to the Trouble Report: https://www.nomachine.com/TR03W11302
NoMachine Network will use whatever is the route set in your network, to reach the remote end-point, to reach the IP. It will use hole-punching and the other methods only if the IP is unreachable, by the standard means, So, in other words, no need “to prioritize the routing” “to go over the tailscale mesh”. But I’d like to understand what you mean with “surrender your keys”. NoMachine Network does not “hand over” any cryptographic information needed to establish the connection. NoMachine Network works only at the “IP level”, all the usual cryptographic security remains in place as it was designed.
Hi, can you do a complete reinstall? Download from this link for the free version:
https://download.nomachine.com/download/9.0/Windows/nomachine_9.0.188_11_x64.exe (64-bit)
https://download.nomachine.com/download/9.0/Windows/nomachine_9.0.188_11_x86.exe (32-bit)
Will Nomachine work with new EGL backend of KDE 6.x?
It already does.
Headless remote login support?
If you refer to the graphic card turning off when the monitor is off or not connected, this is the way the Linux kernel, the graphics drivers, the Linux distributions work, there is no “fix” we can do in our software since it’s not a problem of our software. Annoying? It is. Write an e-mail to your Linux distributor or buy a dummy HDMI display adapter. There are many on Amazon sold for a few bucks.
White screen and then disconnect across most Wayland compositors fixed?
As far as we know NoMachine works with “most Wayland compositors”, already in v8. Specifics please.
Hi Steve, in the public download pages we show the latest version. Customers with valid subscriptions can download version 8 from their User Area. If you write to us though, we can pass you the links to download what you need 🙂
We suspect the wget command failed because the nomachine.deb file that exists there is the armhf file. So remove current installation again and this time try:
wget -O nomachine.deb https://download.nomachine.com/download/8.16/Raspberry/nomachine_8.16.1_1_arm64.debagain.Hi, no there aren’t any graphical restrictions.
Can you submit a screenshot of what you actually see?
Previous reports have revealed that Raspberry Pi reports a 64-bit kernel. This is why uname -m command shows aarch64. However, the OS is actually 32-bit-based. Could you try installing a package suitable for ARMv7?
Links to similar posts:
https://downloads.nomachine.com/download/?id=108&distro=Raspberry&hw=Pi3
I see you used
ssh-keygen -m PEM -t rsa -b 4096to generate the keypair.Did you try to use a keypair generated by running:
ssh-keygen -t rsa -b 4096?Hi, it sounds very similar to this bug report.
Cannot login by NX protocol and private key when option ‘Import the private key to the connection file’ is checked
https://kb.nomachine.com/TR05S10271As a temporary workaround, do not check option ‘Import the private key to the connection file’ in the UI.