BerliosProject:FreeNX - FAQ/Problem Solving
From OpenFacts2
Checking the configuration
In the last time there have been several reports of terminated sessions without any apparent cause.
FreeNX has a not widely known feature to check its own configuration:
Run 'nxloadconfig --check' to test the configuration.
If you include this --check (if it gives any errors) plus the server log, you will get help much faster on the mailing list.
Turning on logging
In /etc/nxserver/node.conf set the following:
NX_LOG_LEVEL=6
SESSION_LOG_CLEAN=0
The first line sets the log level for the log in /var/log/nxserver.log. The second stops the server from clearing the logs in the user's home directory. Check <home_dir>/.nx/<C or F>-<server_name>-<display_port>-<session_id>/ for log files errors and session.
You wrongfully get logged in as a user called NX
If you experience that you are logged in as a user called 'nx', this is because you have enabled too many atuhentication sources at the same time in node.conf.
Example of a wrongfully node.conf file with three different authentication sources enabled at the same time:
# This adds the usermode to the possible authentication methods # Usermode means that a user can start the nxserver as his shell # and connect directly to the right server via a custom client. ENABLE_USERMODE_AUTHENTICATION="1" # This adds the passdb to the possible authentication methods ENABLE_PASSDB_AUTHENTICATION="1" # This adds SSH to the possible authentication methods. For it to work sshd # must be set up at localhost accepting password authentication. ENABLE_SSH_AUTHENTICATION="1" # This adds SU to the possible authentication methods. For it to work the # "nx" user must be in the wheel (RedHat, Fedora) or the users group (SUSE) # and the user logging in must have a valid shell that accepts the -c # parameter. #ENABLE_SU_AUTHENTICATION="0"
Normally, I would recommend that you either use SSH authentication, PassDB authentication (which is depreciated to use) or usermode authentication - no two, or more, sources at the same time (though I haven't tried if there are any combinations that works/don't work).
I get "Time out after 32 seconds" and/or a black screen while trying to connect to a FreeNX server running on a Fedora Core 5 system.
FC5 uses X11R7 which places files in different locations than in X11R6 (monolithic) X. You can possibly fix these problems by renaming "/usr/X11R6" to "/usr/X11R6_old" as root. (NOTE: you should do this ONLY on Fedora Core 5 or later, or other systems running X11R7.) This directory exists only for backwards compatibility with a few old apps (the only FC5 package that puts anything into it is xorg-x11-font-utils, and it only puts two symlinks into /usr/X11R6/bin).
Test NX connections again, and make sure your X login and programs are not broken. If need be, you can revert the change.
That didn't work, or I don't have X11R7. I still get a black screen on login.
If you are trying to connect to a GNOME session, there were problems prior to FreeNX-0.4.4 that sometimes resulted in a black screen on login. If you are running Fedora, you should try the packages here, which contain the fix: http://fedoranews.org/contributors/rick_stout/freenx/
I can't get sound to work
FreeNX primarily supports ESD sound system, so might need to install support for it on the server (some applications must be configured to use ESD). On Debain and Ubuntu you need to install 'esound-clients' to have normal sound-effects sent to the nxclient and played there. If you want to stream MP3, you must install support for ESD output. On Debian and Ubuntu this is called 'gstreamer0.10-plugins-ugly'.
I'm using a PaX enabled kernel, and cannot connect to the server.
If you have a look at the users session file (locate in ~/.nx/$SESSION/session), you might find an error message like this:
/usr/NX/bin/nxagent: error while loading shared libraries: /usr/NX/lib/libXcompext.so.1: cannot make segment writable for relocation: Permission denied
You'll get this error, because the nxagent binary contains "text relocations" and you have CONFIG_PAX_NOELFRELOCS=y (Disallow ELF text relocations) set. To be able to run nxagent, you'll need to disable the MPROTECT check. This can be done with the paxctl tool, like so:
paxctl -m /usr/NX/bin/nxagent
You'll get the same error when xmessage is run - xmessage is the program which prompts if the session is to be terminated or suspend. Thus, run paxctl on xmessage as well:
paxctl -m /usr/bin/xmessage
A.Skwar 15:43 Apr 16, 2006 (BST)
== Workaround for foreign characters in hostname
> Error: Can't determine the location of the X display socket. > Error: Error 2 'No such file or directory' checking > 'C:\DOCUME~1\ADMINI~1\NX73F8~1/D-Fahn›øe-C7E8CA86E07A21252DAC63AB0FD18ACC/.X11-unix'. > Session: Session terminated at 'Sun Sep 2 18:57:23 2007'. >
OK, I seem to have found a work-around to fix this problem: Disclaimer: The work-around involves changing the hostname while the nx client starts up, I'm not sure if the work-around can create problems with other applications, but it is my feeling that Windows don't use the tcpip parameter hostname to much.
Set the hostname registry variable to something different while nxclient
starts up. ie. this vb script:
username = "user" tcpip_params = "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\" old_hostname = WSHShell.RegRead(tcpip_params & "Hostname")
Set WshShell = CreateObject("WScript.Shell")
' Set the hostname WshShell.RegWrite tcpip_params & "Hostname" , username , "REG_SZ"
' Start the client WshShell.Run "nxclient.exe myprofile.nxs"
' Wait for 30 seconds and then... WScript.Sleep 30000
' Reset the hostname WshShell.RegWrite tcpip_params & "Hostname" , old_hostname , "REG_SZ"
Best regards Jakob
Solutions for NX Clients versions 2.0.0 and FreeNX 0.4.x and 0.5.0.
If you have problem connecting with new NX Client ver. 2.0.0, there are 2 patch, which working for me with NX Client ver. 2.0.0-93:
'fake cookie authentication problem':
Some new clients uses 1.4.0 as proto version. You have to make sure that 'fake cookie authentication' is working on the server. Look at nxnode and search for that string in 'node_startsession()' function and edit it.
For freenx 0.4.x nxnode in function 'node_startsession()'
if [ "$ENABLE_1_5_0_BACKEND" = "1" -a "$clientproto" = "1.5.0" ] || [ "$ENABLE_1_5_0_BACKEND" = "1" -a "$clientproto" = "1.4.0" ]
then
# enable fake cookie authentication
cookie=$proxy_cookie
fi
For freenx 0.5.0 nxnode in function 'node_startsession()'
if [ "$clientproto" = "1.5.0" ] || [ "$clientproto" = "1.4.0" ]
then
# enable fake cookie authentication
cookie=$proxy_cookie
fi
Pre 1.5 clients will face trouble in this case, though - but works for me (no users with old clients). As I see in comunnication with client ver. 2.0.0-93, it use 1.5.0 proto version, so this is for older 2.0.0 clients.
'Backingstore problem':
Thorsten Sandfuchs found some issues concerning backingstore. Problem arouse as you try to connect to a 0.5.0 installation with no 2.0.0 backend support and a 2.0.0-client. As Nomachine changed the behaviour of the backingstore-option. In 1.5.0-clients the client sends "always, when_requested" et all and freenx just passed this string to the nxagent-call. The new client now sends "backingstore=1" and the 1.5.0-nxagent issues a warning and an error with "no argument requiered for -bs" or with "Error: NX Agent exited with exit status 1.". You can read all his message here: Backingstore or 2.0.0-client and 1.5.0 backend and freenx-0.5
Look at nxnode and in function 'node_start_agent()' after this line
[ -n "$backingstore" ] && B="-bs $backingstore"
add this lines:
# backingstore = { "when_requested", "always", ... }
[ -n "$backingstore" -a "$ENABLE_2_0_0_BACKEND" != "1" -a "$backingstore" != "1" ] && B="-bs $backingstore"
# backingstore = 1 (new nxclient 2.0.0 doesn't send any strings in the option-string for backingstore anymore)
[ -n "$backingstore" -a "$ENABLE_2_0_0_BACKEND" != "1" -a "$backingstore" = "1" ] && B="+bs"
# backingstore = 1 and 2.0.0-Backend EXPERIMENTAL
[ -n "$backingstore" -a "$ENABLE_2_0_0_BACKEND" = "1" ] && B="-bs $backingstore"
This works using nxclient version 2.0.0-98.
--Predseda3D 15:12 Aug 2, 2006 (BST)
Unable to find 'fixed' font:'
On Debian, the removal of /usr/X11R6 allows the freenx packages to get out of sync with the distribution. While testing nxagent, I found that the program was unable to find the fonts because it was looking for them where not fonts live. The solution was simple, link to the new location of the fonts.
# cd /usr/X11R6/lib/X11 # mv fonts _fonts # ln -s /usr/share/fonts/X11 fonts
-- beewoolie 2006.09.27
nxclient downgrade:
The new versions of nxclient available from NoMachine don't seem to work with freenx-0.4* and maybe also above. There are still some packages of the old 1.5 versions which work fine with freenx-0.4 available:
Ubuntu/Debian: http://free.linux.hp.com/~brett/seveas/freenx/pool/dapper-seveas/freenx/nxclient_1.5.0-141_i386.deb Windows: http://www.ghsix.com.br/downloads/nxclient-1.5.0-138.exe
When I connect, all I get is a blank screen
There appears to be a problem in nxnode, the line that reads;
DISPLAY=unix:$display ...
Change to;
DISPLAY=localhost:$display
This makes a surprising difference (!)
Instead of fonts I only get a square and xlsfonts does not report all fonts
Try the following hint that came by mail:
Hi,
I had a similar problem on Fedora Core 6 + Windows client. xlsfonts was reporting only ~ 300 fonts, none of which were in the times or helvetica families, whereas I was trying to run an application that required fonts in the above families. I was also seeing strange Emacs behavior you described. After wasting all of last Sunday messing with the various font path settings in /etc/nxserver/node.conf, downloading the free server from !M and trying it (same result), I finally realized that the problem must be on the client side. Indeed, when I first encountered NX, I did a testdrive with their server, which installed the plugin. I then downloaded the full client and also installed all the additional fonts that !M provides. The fonts went into C:\Program Files\NX Client For Windows. However, when I looked at the "System Directory" under "Environment" settings of NX client, it was still pointing at the plugin subdirectory, rather than the directory where the full client was installed. So it looks like the client was never finding the additional fonts that I installed. It also appears that, upon connection, the client and the server negotiate a lowest common denominator in terms of installed fonts. So, even though I had all the needed fonts on the server, they must have been discarded during the negotiation process.
Anyway, bottom line: check the "System Directory" under Environment setting and be sure that it point to the directory where the client is installed, rather than the plugin.
| FreeNX wiki Main Page and FAQ | FreeNX homepage | FreeNX mailing list archive | FreeNX@berlios |
