Troubleshoot installation and registration

This section lists some possible post-installation issues along with corresponding corrective actions when applicable. If corrective actions do not remedy the issue, check the Support tools section for more information, or contact support at

Transfer CFT installation

Installation fails due to InstallBuilder issue

UNIX systems

You cannot run the InstallBuilder if the noexec mount option is set on both the /tmp directory and the user's homedir. For example, the installation will fail if you are running unattended mode for a target machine where the user has this mount option set on both directories.

Workarounds include:

  • Remove the noexec option from one of the partitions.
  • Run the .run with a user who has the necessary rights, for example sudo.
  • Create a temporary /home directory on an unprotected disk:

sudo mkdir /instcft

sudo chown <user>:<user> /instcft

export HOME=/instcft (unprotected disk)

./ --mode unattended

Copilot server issues

Copilot doesn't start

  • Check that the port is not already used by another application.
  • Close all active sessions, use the syntax: copstop -f
  • Check that there are no orphan "cop*" processes. If there are, manually kill these processes.

Central Governance

Troubleshoot the registration

If Copilot starts, but the Transfer CFT either does not display in the Central Governance Product List or registers in error:

  • Verify the Central Governance IP address (or FQDN) used in the Transfer CFT configuration.
  • On the computer running Transfer CFT, check that you can reach Central Governance at the IP address used in the Transfer CFT configuration.
  • Check that the Transfer CFT appears in the Central Governance logs. If not, typically this is because the Transfer CFT is unable contact Central Governance.
  • In Central Governance check Administration > Services to ensure that Central Governance is correctly started.
  • Verify the shared secret for Central Governance used in the Transfer CFT configuration.
Note See the Central Governance documentation for additional information and details.

Cannot register Transfer CFT with Central Governance (error: (1103))

If you have the following error in the Transfer CFT log:

XFBCOPT S99015 Central Governance: sending self-registration request

XFBCOPT S99015 navigatorNotifSend: Central Governance: sending self-registration request error: (1103)

Handshake failed (1) SSL_ERROR_SSL(1) - error:14090086:SSL routines: ssl3_get_server_certificate:certificate verify failed

This is a Certificate Signing Request / CSR failure because the Transfer CFT truststore does not contain the Central Governance root >CA certificate. Perform the steps described in If CAs change after Transfer CFT registration.

Generic registration issue with Central Governance or Flow Manager

You can use the CFTUTIL CHECK command to validate the coherence of parameters, partners, and the Transfer CFT PKI database.


See also, Use the check command.

Registration or Copilot connection issue

While trying to troubleshoot a non-working registration, you may find there are not enough http traces to diagnose connection issues.

To have more request details between Central Governance and Transfer CFT registration or between heartbeats, set the $_JAVA_OPTIONS environment variables as shown below (on UNIX in this example).

  1. Requests from Central Governance to Transfer CFT (call to webservices):
  2. export _JAVA_OPTIONS=$_JAVA_OPTIONS" -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog"
  3. export _JAVA_OPTIONS=$_JAVA_OPTIONS" -Dorg.apache.commons.logging.simplelog.defaultlog=debug"
  4. export _JAVA_OPTIONS=$_JAVA_OPTIONS" -Dorg.apache.commons.logging.simplelog.showdatetime=true"
  6. Requests from Transfer CFT to Central Governance (registration /heartbeat):
  7. export _JAVA_OPTIONS=$_JAVA_OPTIONS" -Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog"
  8. export _JAVA_OPTIONS=$_JAVA_OPTIONS" -Dorg.eclipse.jetty.LEVEL=DEBUG"
  9. Restart Central Governance to activate the changes.
  10. Ensure the Transfer CFT Connector service in Central Governance is in debug mode:
  11. cli > serviceLog -l DEBUG -name "Transfer CFT Connector"
  12. Return to info mode:
  13. cli > serviceLog -l INFO -name "Transfer CFT Connector"
  14. Check the logs in:
  15. $CG_HOME/runtime/com.axway.nodes.cftconnector_{un_UUID}/uma/logs/provider.log.*

Registration fails after installing in service mode when using a firewall

Windows only, firewall enabled

Transfer CFT cannot register in Central Governance when installing Copilot in service mode.

  • Preventive measure: Deactivate the firewall to perform the registration.
  • Workaround: If you encounter this error, perform the following steps to register:
    1. Stop the Copilot Windows service.
    2. Manually start the service in a DOSBOX to register.
    3. Accept the authorization from the Windows firewall.

Re-register with Central Governance

When Central Governance sends the SSL certificates to Transfer CFT, the UCONF cg.registration_id parameter is set to a positive integer. If an error occurs, the registration process ends in error. To repeat the registration, perform the following steps:

  1. Stop Transfer CFT.
  2. Stop Copilot.
  3. Set the UCONF cg.registration_id to its default value (-1) using the unset command:
  4. CFTUTIL uconfunset id=cg.registration_id

  5. Start the Transfer CFT Copilot. Copilot starts the registration process.

More information

For more information on Central Governance, refer to the Central Governance 1.1.3 documentation.

All Central Governance interoperability parameters are configured with uconf value settings. For more information, refer to the topic UCONF Central Governance parameters.

Transfer CFT server

Cannot start my Transfer CFT

  • Check your Transfer CFT log in Central Governance.
  • From the local Transfer CFT runtime, try to manually start the server. If you cannot manually start the server, refer to Support tools in the Transfer CFT User Guide.

Runtime directory error

Note If an installation that uses symbolic links fails, once the silent files have been corrected, you must delete the Transfer CFT home installation directory to which the symbolic link points. Failing to do so causes the installer to go into upgrade mode.

Additionally, you cannot perform an installation in a directory if the runtime already exists.

Problem with post-install step

If you get a Warning Problem running post-install step message at the end of an installation, check the installation log file. The message ERR: Unable to decrypt the password indicates that there is an issue related to the PasswordsEncryptionKey.

  1. In the file, locate all encrypted passwords and enter the passwords in clear text, then ensure that the PasswordsEncryptionKey field is empty.
  2. Save the file.
  3. Remove the files created by the unsuccessful installation.
  4. Repeat the installation procedure.

Secure Relay certificate issue

Possible cause: The certificate that refers to has changed

The following message displays in the cft.out file:

Error accessing user certificate keystore file <certificate name> (password might be wrong): keystore password was incorrect

Corrective action

You must delete or rename the file that is referenced in the parameter (often it is called XsrPwd.dat). Then restart Transfer CFT.

Multi-node multihost installation issues

Second node or host fails to install


While performing a multihost multi-node installation, where the user has a different UserId (UD) and GroupId (GID) for each host, you successfully install the first node on the first host, which creates the runtime on the shared disk. But the second node or host installation fails with the message:

Warning: The directory


is not writable by the current user

To resolve this issue, using a different user perform the following commands on all hosts that are involved in the multihost, multi-node installation:

  1. Open an SSH session on the machine and run the following command to change the UID, for example:
  2. sudo usermod -u 1005 ithomas
  3. Where 1005 is the desired common UID, and ithomas is the user common to all of the UNIX hosts.
  4. Run the command to change the GID, for example:
  5. sudo groupmod -g 1006 ithomas
  6. Where 1006 is the desired common GID, and ithomas is the group to which the user ithomas belongs.

For more information, please refer to the NFS documentation.

Related Links