General troubleshooting tips
When you are experiencing problems with xfServer, the first thing to do is to check the log. Even when the error is displayed on the client, the server-side logs may contain useful troubleshooting information. On all systems, some basic logging is done by default, with additional logging available.
- Windows: By default, rsynd logs its version, start/stop information, and critical errors to the Windows event log. You can use the “Enable logging” and “Verbose logging” options in the Synergy Configuration Program to turn on additional logging. (See those fields in Modifying the SynSrv xfServer service.) The Monitor utility may also be of some assistance, especially when you require information regarding files that are opened, locked, etc. (See Monitor utility for Windows (synxfmon).)
- Unix: By default, rsynd logs start/stop information and critical errors. (See Logging.) The Monitor utility for Unix may also be of some assistance when troubleshooting.
- OpenVMS: By default, rsynd logs errors and some status messages. You can use the /LOG_LEVEL=FULL qualifier for additional logging. (See Logging.)
Start-up errors (Windows)
When I start the xfServer service, I get the error “A service-specific error occurred: 99.”
See the Windows Event Viewer for additional information about this error.
Log-in errors
What does it mean when a client receives an “Unknown host ‘nnn’ in server spec” error?
It means that the client has no TCP/IP connection to the specified host. Use synxfpng to determine if the client can connect to the server machine via TCP/IP. See synxfpng utility for more information.
What should I do if my client is receiving a “Bad user name, login rejected on servername” error?
This error can occur when you are running in secure mode. There are several problems which can cause this error message.
- RUSER is not set on the client.
- RUSER is set on the client, but the username and password don’t match an account on the server.
- RUSER is set on the client, but the user account has not logged in to the server console. Some systems may require the user to physically log in to the server prior to making a connection to xfServer.
- You are using Windows authentication security, and the client is not in the same domain as the server or did not log in successfully to the domain.
If you are using RUSER security, you should first verify that RUSER is set on the client and that the client has an account on the server using the same name and password. On Windows, you can run synckusr on the server to see where xfServer is finding the client username. You can also run synckusr on the client to see what username and password are being sent to xfServer. See synckusr utility for details. Refer to the following sections for information on how and where RUSER is set:
- setruser utility
- RUSER
- For Windows, Understanding xfServer security on Windows
- For Unix, Understanding security modes on Unix
- For OpenVMS, Understanding security modes on OpenVMS
File permissions (Unix)
How do I get xfServer to create files with user-defined permissions?
To ensure that the desired permissions are used, set the UMASK environment variable. To set UMASK for a specific user, add the following line to the user’s .synrc file:
UMASK=mask
where mask is the octal umask value you want to set. Refer to the octal form of umask(1) in the Unix man pages for details. The next client connection for that user will use umask. To affect all users, you can set UMASK in the /etc/synrc file and then restart rsynd. You can also set UMASK in the environment before starting rsynd to affect all users.
Some security implementations cause the umask value to be cleared. You must use the UMASK environment variable in those instances.
File access (Windows)
What should I do when I get a “file not found” message when starting an xfServer service?
Remove the xfServer service with the rsynd -x command, and then re-register it with rsynd -r. You can also remove and re-register rsynd from the Synergy Configuration Program; see Stopping xfServer and Starting xfServer.
Why do I get a protection error accessing files on xfServer, even though I can access files using mapped drives.
The default search path for user authorization on mapped drives is different from the system call we make to authorize users. The system call LookupAccountName is used to look up security information for a username. It first checks well-known system IDs, then checks local accounts with administrator privileges, and then checks the primary domain. If the username is still not found, it checks trusted domains.
If you want to know where the user account is being found by xfServer, run the synckusr utility on your xfServer machine. See synckusr utility for details. Once you know which machine provided the log-in information, you can check the access permissions for that account on the machine that is authorizing the user. We recommend that each user account have a unique name in a network where several machines could authorize the account.
xfServer is running, but I cannot connect to it from my client.
This is often a DNS problem or a TCP/IP configuration problem. Try using the synxfpng utility on the client to assist your network engineer in troubleshooting the problem. See synxfpng utility for more information.
Rsynd: shutting down and timing out
Connections to the xfServer daemon, rsynd, are normally closed down by the client through normal exit processing, thereby freeing licenses, closing files, and releasing locks. However, if the client dies with a network-related error or a segmentation fault, or if the client machine is turned off or the network fails, rsynd never gets the shut-down request. In such cases, the continued operation of the server process is determined under the rules of the TCP/IP protocol and a timer called the keepalive timer.
The TCP keepalive timer, which is different on all systems, sends a request on idle sockets in an attempt to connect to the client machine and determine if the connection is still valid. (A socket is considered idle if there have been no calls from the client on that socket for the length of time specified in the keepalive timer.) If the connection is broken, rsynd can determine this and shut down, freeing licenses, releasing locks, and closing files.
Because the wait time for the keepalive timer can be as long as two hours on some operating systems, we set it to ten minutes each time a socket is opened. This setting temporarily overrides the system keepalive setting.
|
On Windows, the connection recovery feature, which is enabled by default, has its own keepalive timer setting (see KeepAlive). The ten minute setting described here applies only when connection recovery is disabled. |
