Forum Replies Created
-
Posts
-
A final note, as I wrote earlier, we have already scheduled a maintenance release. We cannot however foresee differences between a beta, Sequoia in this case, and its final release (of September 16) which could lead to some incompatibilities with the NoMachine software, as has happened in this case with the release of the latest macOS version. For this reason we gives ourselves a period of 30 days to make adjustments as written in the article I linked earlier. Problems reported for “Sequoia beta” have been addressed during the development of our release candidate, however those fixes are being revisited to make them suitable for macOS 15 just released. We will update the forums when we have more information.
Here is the related Trouble Report with the possible workarounds: https://kb.nomachine.com/TR09V11212
Hi Me, welcome to the forums.
So was this taken as a bug report as people were obviously testing with those pre-release versions?
I’m not sure what the question is but I can add that we take all users’ issues seriously, including users who test beta versions of supported operating systems. And of course we also test beta versions and use the provider’s beta phase to assess possible solutions for any problems that arise. Fixes are then implemented as quickly as possible and according to our release schedule.
What is the ETA for the fix now that this issue is active on production release of a widely used operating system?
NoMachine aims to become completely compatible within 30 days of a supported operating system production release (this is a general guideline, but we work to make that time as short possible, see the article I linked earlier). We already have a maintenance update planned early next week. That update is being finalized as I write, even at the extent of postponing the maintenance for a few days also to ensure 100% compatibility with Sequoia. As soon as we have more news, it will be posted here.
renatenickole, it seems you are referring to our legacy version (pre version 4) These commands are not supported.
Hi, if you don’t want the server component installed on your machines, try Enterprise Client. It’s free to download and use, suitable for users who only want to start connections to remote desktops (and not receive connections) https://www.nomachine.com/product&p=NoMachine%20Enterprise%20Client.
Or what you can do is install without starting the NoMachine Services automatically, see section 2.8 of this document for example, https://kb.nomachine.com/DT07S00246.
morozov, is your server headless? Enable debug and send us the full logs. Please follow the instructions here: https://kb.nomachine.com/DT07S00243
Also send us the logs in the directory in point 2 above.
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
psantucc
we’re unable to reproduce this behaviour despite several attempts and the logs you sent us indicate nothing strange.
1) can you tell us if the server is headless?
2) send us all the logs in this directory: $HOME/.nx/nxegl/
We have opened a Trouble Report which you can monitor at the following link:
Hi,
is it possible to disable copy/paste function :
– from client (source machine) to server (destination machine) ?
– from server to client ?
Yes, it is possible in all server products, that means also the free version. Here some instructions to disable copy and paste, both directions: https://kb.nomachine.com/DT07S00233#22
Is it possible to create complex rules like:
“Allows copy/paste from server to client only if the client is in LAN” ?
“Disables copy/paste from any client not in LAN”
Rules, via “profiles”, are available in specific products of the Enterprise suite, namely all Cloud Server products, Terminal Server and Enterprise Terminal Server. By federating the smaller Workstations and Enterprise Desktops under one of the Cloud Servers, profiles can be propagated. How to do it? Below is an example, which blocks allows only 192.*.*.* addresses.
$ sudo /etc/NX/nxserver --ruleadd --class feature --type client-clipboard --value no --address 10.0.*.* $ sudo /etc/NX/nxserver --ruleadd --class feature --type server-clipboard --value no --address 10.0.*.*You have the same overlapping issue like in the other topic mentioned above. To fix the overlap you can move the second screen to not overlap the other. For example, arandr will let you do this.
An easy way to fix the overlap is to do
sudo apt install arandrand run that application. It lets you organize the screens and you can fix the overlapping.Hi, adding the possibility to disable clipboard from the client side is already planned. It’s currently in our development roadmap for version 9.x.
Indeed this looks similar to https://forum.nomachine.com/topic/no-fullscreen-across-all-monitors-option-for-dual-screen-setup
Can you send us the output of the xrandr command on the Kubuntu machine?
We noticed that the monitors overlap by 1 pixel.
Screen 0: minimum 320 x 200, current 3839 x 1080
DisplayPort-1 connected 1920×1080+0+0
DisplayPort-2 connected primary 1920×1080+1919+0We are checking on our side what improvements can be done, but if you fix the overlapping of the monitors’ position, it should be OK.
You can login to the server as any other user provided the account is valid on the server. So, there could be users John, Jack and Jill. NoMachine handles key authentication in the same way as SSH. The keys are set per system user account. So, if the desktop on the server is owned by John, the user which connects should login as John. If you login with another valid system user (Jack or Jill), user John will have to authorize the connection.
We’re not able to reproduce it. Can you send us the server-side logs so we can check them? 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. Or you can attach the zip archive here. Thanks!