Forum Replies Created
-
Posts
-
Hi, improvements to the virtual keyboard usage on mobile devices will be implemented in the next update of the app.
why is nxserver looking for user ‘rich’? Any suggestions for this error?
It’s a warning and not an error. You can remove user rich from the usersDB.
sudo /etc/NX/nxserver --userdel richLogs are required from the server side in order to understand what is causing the session to fail. Please follow the instructions here https://kb.nomachine.com/DT11R00182 and then send them to forum[at]nomachine[dot]com.
‘Grab the keyboard input’ option enables the so-called ‘passive grab’ of the keyboard, but it is also possible to enable the ‘active grab’. In order to try this, please quit the NoMachine player application completely (you can do this from the NoMachine icon in the tray) and start it again from the terminal using the following command:
/usr/NX/bin/nxplayer --activegrabAfter that, whilst the session is running, go back to the menu and select the box for enabling ‘grab the keyboard’. Does this help?
Backtrace is empty because the process isn’t running any more. Please follow the instructions from https://forums.nomachine.com/topic/manjaro-ubuntu-connection-problem#post-39275.
Run
coredumpctl listYou will receive output like this:
TIME PID UID GID SIG COREFILE EXE SIZE Thu 2022-07-15 19:48:13 CEST 120316 1000 1000 SIGSEGV present /usr/NX/bin/nxplayer.bin 2.1Mthen depending on the PID number of the nxplayer crash, please execute:
coredumpctl gdb 120316 --debugger-arguments="-batch -ex 'thread apply all bt'" > /tmp/crashReport.txtthen please send us /tmp/crashReport.txt crash report file.
In our example the PID is 120316. You will have a different PID number for the nxplayer process. Please use the PID number that you see in your output of
coredumpctl list.coredumpctl gdb 120316 --debugger-arguments="-batch -ex 'thread apply all bt'" > /tmp/crashReport.txt No match found.You didn’t use the correct player PID. ‘120316’ is the player PID in our example. In your case, in the output of coredumpctl we see PIDS 204956 or 205743 (these are the last 2 we see in the list).
So run
coredumpctlagain and this time check the PID number next to the nxplayer process. Use that PID number in “YOURPID”:coredumpctl gdb YOURPID --debugger-arguments="-batch -ex 'thread apply all bt'" > /tmp/crashReport.txtto get the crashreport.
Apologies, I didn’t realise you were using the Wizard on the mobile app to start the connection. The app is not yet aligned with the desktop version, so I confused you no doubt when talking about ‘Configuration’, where you have ‘Advanced’. Also, I mentioned the wrong tutorial. I should have pointed you to the tutorial here: https://www.nomachine.com/getting-started-with-nomachine-for-android. All our tutorials are available in our support section (nomachine.com/all-documents) of the website by the way.
Version 8 of the mobile app will be released after we’ve released version 8 for desktop, and so the wizard will be removed and other elements will be improved to make connection creation as seamless as possible.
I confirm what Fisherman says about SSH. Connections using SSH are not available in the free version.
Hi, please take a look at the answer from zaq in the topic here: https://forums.nomachine.com/topic/nomachine-broken-on-windows-10#post-33133.
ericmock, instead of killing the process, grab a backtrace from it:
gdb -batch -ex "thr apply all bt" -p 12345 > gdb.outwhere 12345 is the pid number. Send us the output.
From https://forums.nomachine.com/topic/manjaro-ubuntu-connection-problem,
can you please execute some commands to collect core stack and send it to us
coredumpctl listYou will receive an output like this:
TIME PID UID GID SIG COREFILE EXE SIZE Thu 2022-07-15 19:48:13 CEST 120316 1000 1000 SIGSEGV present /usr/NX/bin/nxplayer.bin 2.1Mthen depending on the pid number of the nxplayer crash, please execute:
coredumpctl gdb 120316 --debugger-arguments="-batch -ex 'thread apply all bt'" > /tmp/crashReport.txtthen please send us /tmp/crashReport.txt crash report file.
It’s an issue we are aware of and will be fixed in the next software release, version 8. A restart of the nxserver can sometimes help which I can understand is not the best of workarounds, and as akorzy mentioned, didn’t work for him in his case.
Can you update to the latest version 7.10, both sides, and tell us if you are still experiencing the issue?
Having an “Auto” option is perfectly possible. You will surely ask why we didn’t do that already.
The reason is that, at the time, when we initially evaluated it and decided what to do:
– The situation on the Mac was absolutely all fine and all clear. No problem.
– The situation on Windows was complicated. This setting is exposed only to UWP applications, whereas NoMachine is obviously not, NoMachine is “native”, and it was unclear if there was any “functional bridge”, between this setting and these “go light”, “go dark” events that were exposed to UWP applications and not to “native” ones.
– The situation on Linux… OK, you get it 🙂
Try in the server configuration file:
#
# When ‘CreateDisplay’ is enabled, specify the display owner and let
# NoMachine create the new display without querying the user. If the
# server supports only one concurrent connection, the connecting user
# must be the display owner set in this key.
#
#DisplayOwner “”See also this article:
Connecting to Linux headless machines with NoMachine
https://kb.nomachine.com/AR03P00973This sounds like a permissions issue. What workarounds did you already try?
You should take a look at this article in our KB:
How to install NoMachine on macOS Catalina and later
https://kb.nomachine.com/AR11Q01061There is a section for audio issues as well.
Please see the topic https://forums.nomachine.com/topic/manjaro-ubuntu-connection-problem where you will find an explanation and a temporary workaround.