Forum Replies Created
-
Posts
-
Hi, please try the Workstation for Linux and see if it fits your requirements. If you create a NoMachine account, from your User Area you can generate an Evaluation license for any NoMachine product from the Enterprise family of products (Terminal Server, Enterprise Desktop and Cloud Server products).
Screen blanking blanks the physical screen, and the main physical session is on that physical screen which you just blanked 🙂 If local users want to be able to work on those Linux machines while the screen is still blanked, the product you need could be NoMachine Workstation from the NoMachine Terminal Server suite. This is a family of products available for Linux, and lets users have a physical desktop and a virtual session, one that is completely independent and with which you can interact even if the physical desktop is blanked, the physical desktop of the machine where the virtual session is running, is blanked.
Take a look at the following resources:
https://kb.nomachine.com/AR10K00700
https://www.nomachine.com/enterprise/terminal-server-products/workstationIn v9, we implemented changes to how the reconnect works. In order to add a further layer of security to the reconnection, we no longer use the user credentials, but connect and authenticate to the server through a security token. This token has a short expiration time, so when the lid is opened and the notebook system restored, the server rejects the automatic reconnection token authentication. So it’s not possible to reconnect without any user interaction. We are going to add a new key to the server which will allow the token expiry to be configured per user needs.
Please take a look at the dedicated article about how reconnection works:
Hi, there is known issue on Wayland. You could try disabling Wayland and using Xorg instead to verify if it’s the same problem. Does the problem go away? Here is the link to the Trouble Report: https://kb.nomachine.com/TR08T10575.
Screen blanking is supported in all products. We are not aware of screen blanking issues when connecting to a physical desktop on XFCE. Does it also not blank screen from the !M icon of the system tray? (Desktop shared > Blank physical screen). Can you send the us the logs of the server host? Reproduce the issue again, then on the server host, go to the Server settings > Security > scroll down and click Take logs). You can attach them here or if you prefer send direct to forum[at]nomachine[dot]com. Thanks.
Hi,
from what you’ve written it seems you are activating screen blanking on the wrong side. Screen blanking blanks the screen of the target computer, the one you are connecting to. So, in your case, you have two Windows computers, let’s call them “A”, the computer you are connecting from (the “client”). And “B” the machine you are connecting to (the “server”). This means that to activate screen blanking, you must configure machine B, the server, to blank the screen.
You have two choices. You can either configure the ‘Server settings’ on machine B by enabling the box “Blank the physical screen when somebody connects” (Go to Server settings of Machine B > Security > tick the box ‘Blank the physical screen when somebody connects’. Or you can blank the screen during the session from the !M icon on the target desktop: i) start your NoMachine connection from A, ii) login to B with your system credentials, iii) go to the !M icon of the system tray on machine B, iv) click ‘Desktop shared’ and then toggle ‘Blank physical screen’.
We were able to report the issue. You can track the status of the fix using this link here: https://kb.nomachine.com/TR02X11712.
Thanks.Unfortunately, there’s not much more we can debug. Although we would appreciate knowing if the the monitor issue disappeared when you set
--eglcaptureto no using the last package we provided.Hi, first let’s explain how the resize works. When the resize remote display is enabled, the remote desktop and the local window geometries are always synchronized. If the remote desktop changes its geometry, the client adapts the window size. When the client can’t fulfill a request to change the window size (usually, because the size is bigger than the client monitor), since the server has priority over its resolution (i.e. the client can’t “force” it back), then the mode automatically switches to viewport mode.
Now, it’s not clear to us what is happening when the “session times out due to inactivity” – we are happy to check the logs and that will let us also check the sequence of events occurring when you encounter the error. However, the technical behaviour is the one explained above, it is exactly how resize works when giving priority to remote desktop resolution.
We do have a Trouble Report open which has a workaround which you could try. Basically, the slider setting is ignored when disconnecting and connecting again to the same desktop. We are not sure if this is your case, https://kb.nomachine.com/TR07W11470.
To get the logs from the macOS client, reproduce the problem first, then, still on the client, go to Settings -> Player -> Security and ‘Take logs’.
Hi, can you send us the logs from both client and server sides?
You can extract them using the instructions here: https://kb.nomachine.com/DT08U00298. You can attach them here or send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!Hello,
can you follow the instructions here:
How can I send Ctrl+Alt+Delete to a remote desktop?
https://kb.nomachine.com/AR02L00784and if there is something that is not working as described there, please tell us?
Hi,
Local network connections don’t save a file in Documents\NoMachine, because of the ephemeral nature of automatic server discovery e.g., a machine might be temporarily unavailable or change its local address, and so on. Local server connections are stored in a temporary cache, where the cached connection files keep user preferences, but automatically update the server address and protocol information.
You have two options:
i) From the Windows player, create a new connection file manually and set the local LAN server’s IP in the Host field. The “Direct connection over the Internet” description that you see there might be misleading you. Creating a connection this way is not limited to WAN addresses only. Choosing this way to connect is useful only if the server IP doesn’t change.
ii) From the Windows player, in the Machines panel, edit the connection you want to launch automatically (right click on the connection icon), select Info in the left menu, copy the UUID visible in the Software group on the right, and look for the cached NXS file: %USERPROFILE%\.nx\cache\
.nxs. Note however that when the system starts, the client has not yet received the broadcasted server address, so the one stored in the cache could be old and the connection may fail. Consider giving the Mac server a static LAN IP (in such a case, solution 1 would be easier).