Forum Replies Created
-
Posts
-
Hello.
The DefaultDPI in node.cfg controls the value of Xft.dpi resource. You cannot specify it per-session, but you an create a user specific node.cfg: just copy the original node.cfg to a new file called username.node.cfg (specify the user’s name in place of “username”) and edit username.node.cfg according to your needs.
Sorry, disabling only for a specific application is not possible.
What happens exactly when the clipboard gets full? Does NoMachine client crash? Or the server?
Are you connecting to the server physical display? Or are you creating a virtual desktop session?
Could you tell me the version of Rhapsody are you using and a few steps to reproduce the issue?
Would you be willing to try a debug version to help us find out what the problem is?
Hello,
It is possible that the Raphsody output automatically passed to the clipboard and then it went to the NoMachine client. This is needed to automate the process of copy-and-paste text from the remote session to the client host.
If you don’t need such feature, you could try editing the file /usr/NX/etc/server.cfg to add the line:
EnableClipboard none
This would disable the transmission of clipboard content to the client host, so it should work around the problem.
Could you provide more details about your configuration, like
– Does the problem arise in connections to physical display or to a virtual desktop?
– What are the desktop environments in use on client and server (Gnome, KDE, etc)? What are the Linux versions in use?
– How is the Ctrl/CapsLock configured (xmodmap, Gnome keyboard settings, etc)? Is it done on client or server (or both)?
Hello,
May I suggest you disable display acceleration on the server? Article https://www.nomachine.com/AR02L00782 shows how to do it.
We reproduced the issue with your configuration.
It occurs only in “lightweight” mode. If you want you can disable lightweight mode editing node.cfg:
AgentLightweightMode 0My desktop uses Win81, the Power Option is set to Turn off the display = Never when plugged in.
What about the desktop of Linux server you are accessing?
The NoMachine window goes black at 5mins, requiring me to login again.
Did you go to the Gnome screen saver setting to change the timeout value?
Hello.
It is likely a known problem. Could you help me to identify it?
The known problem affected only the up key, while other arrows worked normally. Setting the desktop environment to change shortcut from the Print key to something else (let’s say Alt+p) helped: the up arrow came back to work properly.
Hello.
There is no option in NoMachine to set the inactivity time out. It is a feature of the desktop environment, NoMachine is not supposed to change that value.
Could you tell us how much quickly the display locks? After few seconds or what?
Which Linux OS are you using? Gnome or KDE?
Hello.
Which is the exact Ubuntu version? 13.04 or 13.10? 64 or 32 bits?
Are you using the default cursor them? Or did you switch to a custom theme?
Is the desktop environment the default Unity desktop shipped with Ubuntu?
Cursors in the desktop change from window to window. Does the cursor sometimes show itself or is it always invisible?
Hello Romn,
when more monitors are in use on the server, NoMachine captures the whole virtual screen extending on all monitors. As the client is set to scale the captured screen to fit in its window, you could find that the resulting image is too squeezed if the server screen is much larger than the client window.
In case like this it is better if you set the client not to fit in the window: run the NoMachine session, press Ctrl+Alt+0, click on “Display” and turn off the option “Fit to window”.
About the keyboard, please send log files to us in order to check for possible problems. By the way, what you described looks the expected behavior. The layout that matters is the one set on the server. You need to change the server setting in order to match the client keyboard.
You can find instructions to gather server side logs here: https://www.nomachine.com/AR07K00677
Could you please specify the exact version of RHEL are you using?
Do you confirm that just installing version 4.2.17 is enough to create the problem? Does the problem show up in the console even if you never used NoMachine for the remote access?
Does the problem occur after you stopped the server (/usr/NX/bin/nxserver –shutdown)?
Is it possible for you reproducing the problem and sending the server logs and the output of ps -ef –forest?
You can find instructions to gather server side logs here: https://www.nomachine.com/AR07K00677
Can you please explain this better? What do you mean with “which we access outside of NoMachine”? How going from one NoMachine version to the other may affect the program if you are not accessing it through NoMachine?
Could you send the output of ps -ef –forest at the time the problem occurs?
Have you also checked Gnome logs in $HOME/.xsession-errors?
tcp 0 0 0.0.0.0:7001 0.0.0.0:* LISTEN 20758/nxnode.bin
tcp 0 0 0.0.0.0:7002 0.0.0.0:* LISTEN 26853/nxnode.bin
tcp 0 0 0.0.0.0:7003 0.0.0.0:* LISTEN 16466/nxnode.bin
tcp 0 0 0.0.0.0:7004 0.0.0.0:* LISTEN 21998/nxnode.bin
Those ports are the TCP X11 display ports. You have four node processes. Each node is listening on a different X11 display.
In X11, the port number and the display have a fixed offset of 6000, that is TCP Port = Display Number + 6000.
So that, those nodes are listening on X11 displays :1001, :1002, :1003, :1004. NoMachine is set to begin display count at 1001. New node processes will get progressive numbers.
Sorry, we’d need content of .nx directory from server side, too.
Please, connect to the server and run form a terminal:
$ tar -cvp –exclude ‘cache*’ –exclude ‘images’ –exclude ‘recording’ -f – $HOME/.nx | gzip -c >nxdir.tar.gz
Other pieces of information that could help can be gathered running the commands:
$ xmodmap -pke > xmodmap.txt
$ xprop -root | grep XKB > xprop.txt
Please note that a new version (4.2.17) is available. Let we know if you find the same problem after the upgrade.