Forum Replies Created
-
Posts
-
Keyboard in version 3 (in NoMachine products and any other product derived from the same NoMachine version 3 software) worked in a completely different way, compared to version 4. In version 3 the keymaps of the client were uploaded to the agent X server, so that the X applications saw the same X keycodes as stored on the client. In version 4 the keycodes are sent by the client untranslated and the translation happens inside the target X server, according to the keymap selected by the user. This change is obviously for the better and allows the user to simply change the keyboard layout by selecting the keyboard in the control panel of the desktop environment. If you were running a previous version of NoMachine (or an alternative product based on the same NoMachine software), what we suggest is ensuring that you don’t try to load any special keyboard command on the client and that you don’t change the keyboard on the server upon running the NX session, for example to try to correct a keyboard problem encountered running an older NoMachine version.
Regarding your specific issue, you don’t specify which NoMachine version you run on the server, but we suggest you upgrade to the 4.0.366 since it included one fix that was specifically aimed at solving AltGr keyboard problems.
There doesn’t seem to be anything abnormal in the stats.
Can you attach also client-side logs? You can find them in the .nx directory in the user’s home.
Have you tried disabling UDP from the Advanced connection settings?
Also please paste the statistics after a freeze occurred.
You can take them clicking on the Connection icon of the toolbar.It’s very likely that you can’t get an additional public IP for free, since you are on a hosted facility. But you may try to create a tunnel to 162.243.14.121 and from 162.243.14.121 to 10.0.2.15 port 4000.
ssh -R 4500:localhost:4000 user@162.243.14.121
It won’t work as fast as a direct connection but better than nothing. Be also sure you disable UDP in the connection setup.
Otherwise I strongly suggest you ask to the help-desk of the provider offering the hosting service.
Hi.
It looks like a known issue with sharing a 16 bit physical display.The bug is tracked in the following Trouble Report:
https://www.nomachine.com/TR11K04037
The fix will not be ready for the upcoming release, but you can expect it to be fixed in the next one, which is likely to take place in the next week.
Check if you have a core dump in the home directory of the user owning the session.
Please also attach the logs files:
# tar zcf logs1.tar.gz /usr/NX/var/log
# tar zcf logs2.tar.gz /home/<user>/.nxBe sure you include all the information listed here:
– NoMachine product and version on local and remote machine (free version, Workstation, etc).
– Whether the problem arises connecting to a physical or a virtual display.
– Remote and local Windows/Mac/Linux version (Windows XP/7/8, OS X 10.x, Ubuntu xyz, Mint x.y, etc.).
– If on Linux, desktop version (GNOME. KDE, whatever) on client and on server.Where did you set that? You must set it on the server, in the target user’s home, not on the client.
Don’t forget also to export the variable:
export LANG=”it_IT.UTF-8″
Hi.
It could be some environment variable that is missing in the start command of your desktop manager.Please copy&paste the output of the “env” command, as run in the physical desktop and on the virtual desktop session.
That is:
Open a terminal on the physical display and run:
# envStart the new remote desktop session on the NoMachine server.
Open a terminal and run:
# envPlease provide the complete output.