Open topic with navigation
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.
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.
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.
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:
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:
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.
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 is normally about two hours on most Windows and UNIX 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.
On OpenVMS, the amount of wait time is much less; you can check the setting and reset it if necessary in TCPIP. See your OpenVMS operating system documentation or supplier for details.