Forum Replies Created
-
Posts
-
The Workstation Server is part of the Terminal Server family, so the normal behaviour described by Britgirl is the reason why you see that panel. If you need to force the automatic connection to the physical desktop you could use a debugging feature: press Ctrl+Alt, right click the Physical Desktop item and select “Always connect to this desktop”. Please note that this configuration is not meant to be used to bypass the desktops list panel, so for example when you’ll restart that server the physical desktop session ID will change, and you’ll have to repeat the same operation.
By the way, don’t forget you have a direct channel to the support team with subscriptions from our Enterprise suite.Hi Chris. We confirmed the issue and implemented a fix, it’ll be included in our next maintenance. Thank you for the report.
Hi Steve. Yes, when the client detects that the server is configured to disallow credentials storing, the existing authentication data gets cleared and no longer saved.
What’s slightly odd is there seems to be some interaction between the client and the server before this happens… the screen appears very briefly to have the preferred resolution… then it flickers and goes back to the higher resolution. I can upload a video somewhere if that helps to illustrate, but it’s bigger than the 1024k allowed by this forum.
Oh, I see, that means the client tries to set the resolution but Ubuntu is changing it back to the previous one. Are you connecting to the Ubuntu physical desktop or creating a new virtual desktop?
If you have the file.config/monitors.xmlin your home directory, can you try to rename it, logout, login and try to check if Ubuntu keeps the custom resolution when the client connects?Hi again. When the input stops working, you can disconnect and connect again the keyboard (for example turn it off/on or detach/attach the cable, if wired) to restore its functionality.
I confirm the fix is ready to be released, so we’ll publish it as soon as the other major changes are ready.Hey there, thank you for your reports!
For the first problem, can you try to enable the “use custom resolution” box and set the W 1280 and H 1024 resolution? This should work around the problem while we debug the reason for the ignored resize request.
For the second problem, we’re aware of it and we implemented a fix that will be included in the incoming release. I don’t remember if there was a method to work around it, I’ll talk with the team and let you know.
On the main window, when you right-click on a client machine, the selection marker rapidly moves up and down at a high frequency.
Can we exclude ghosts? 🙂 Can you please confirm if you’ve this popup issue on the client host, or in a NoMachine client running inside a NoMachine session? Also, in the former case, what is the Linux distribution version? Kernel version is important, but since we’ve to try to get a configuration as close as possible to the one you use, it is way better if we start from your same distro version.
All’s well that ends well! 😀 Kidding aside though, there must be a reason somehow connected to your ssh tools and I would not exclude that it’ll happen again in future. We’re here to assist you in that case. Long live the keys!
For some reasons, the key attached to the post is not valid, I’m getting these outputs when testing it with openssh 9.6p1
ssh-keygen -l -f testkeyfornomachine 256 SHA256:eWl6FVVBI16fflrvux+rY0JgcV0bQmeKaTdktJi0RGQ “TestKeyForNoMachine” (ED25519) ssh-keygen -y -f testkeyfornomachine Load key "testkeyfornomachine": invalid formatIf you run the same commands on your end, do you get anything different?
While editing the Trouble Report with the recommendation submitted by @neatchee I noticed that there are some additional questions we can ask to collect details for the debugging, so here they are:
- Besides the key type security concerns, we assumed that the RSA key login is still working correctly. Could we get a confirmation?
- Where are the ED25519 and ECDSA key files located on disk? Did you maybe try to move them in different system folders (e.g. $HOME, tmp/, .nx/) to verify if anything changes?
- Are key access permissions correct, so both folder and file can be accessed by the user starting the player process?
- Can you share any of the key pairs not working, so we can test them in our labs? You can contact us at forum[at]nomachine[dot]com.
Thank you for helping us to debug this mysterious issue!
Interesting, process could not even create the logs directory. Please run the command
/usr/NX/bin/nxplayer --log stderrin a terminal, let me know what you see there as output.Usually aborts are tracked also in client logs, so we’ve a good chance to find useful hints there. Could you pack your
$HOME/.nxfolder and send it to forum[at]nomachine[dot]com, please?Hi. There are no known issues like the one you’re experiencing, so we can troubleshoot it together by starting from a check of
journalctl, it will help to verify if the client is segfaulting. Try to start it, then runjournalctl -rand check if the processnxplayer.binwas closed because of a segfault. Copy the line and paste it here in the thread.