ecs-sync is an open-source tool. As such, there is no commercial support for its use (any support provided on github is best-effort and community-based). If you plan on migrating your production data, you should consider a Dell Professional Services migration package. The Dell PS team have extensive knowledge of ecs-sync and a migration package comes with the full commercial support of Dell EMC engineering.

• UI
  • Grails Error on First Login
  • Attempting to Initialize Shows "Missing Configuration" Error
• CAS
  • UnsatisfiedLinkError
  • Unexplained CAS object failures
  • CAS-related core dumps
  • OutOfMemoryError in 3.2.6+ with large blob count
  • Extremely slow CAS migration
• General
  • SSLHandshakeException when using SSL to connect to storage
  • "Sync Options" fields required when creating a new sync
  • "Skipped" objects appear on first run of a sync
  • SQLException after upgrading to 3.2.5
  • MySQLSyntaxErrorException after upgrading to 3.2.9
  • SAXParseException during S3 bucket migration

This is expected and can be ignored. The error will resolve once a new user email is successfully submitted to the UI. See Initializing the UI for more information.

Sometimes attempting to initialized will show the "Missing Configuration" error. This is likely because the user has entered their email address and pressed Enter. This action will throw the above error every time. The user must click the "Save & Write Configuration to Storage" button for the email to be correctly saved. Until the email is successfully saved the UI will remain un-initialized and the user will not be able to proceed. See Initializing the UI for more information.

If you see the following as a general error of a sync job or in the ecs-sync.log file:

General Error: [java.lang.UnsatisfiedLinkError: com.filepool.natives.FPLibraryNative.setLastError(I)V] java.lang.UnsatisfiedLinkError: com.filepool.natives.FPLibraryNative.setLastError(I)V
    at com.filepool.natives.FPLibraryNative.setLastError(Native Method)
    at com.filepool.fplibrary.FPLibraryException.retrieveErrorString(Unknown Source)

This means that ecs-sync cannot find the CAS SDK binaries. Make sure the following are true:

• You have installed the CAS SDK in its default location (/usr/local/Centera_SDK)
• The following lines are present in /root/.bash_profile:

export LD_LIBRARY_PATH=/usr/local/Centera_SDK/lib/64
export FP_LOG_STATE_PATH=/var/log/ecs-sync/cas-sdk.config

Note: the configure-centos.sh script (used for Service Installation) creates these lines automatically.
You may need to restart the ecs-sync service for these variables to take effect.

If you cannot find an explanation for CAS object failures, try turning on CAS SDK logging, which may provide additional info.

If you are running a CAS migration and see core dumps (where the ecs-sync service dies), you may be hitting a socket limit on Centera. To avoid this, you should try lowering your total thread count. If that still does not work, you can try upgrading to 3.2.3+ and disabling estimation.

If you see the following error on 3.2.6+ and your source clips have many blobs (more than 50 per clip):

java.lang.OutOfMemoryError: GC overhead limit exceeded

You may need to enable a new "large blob count" feature. This feature was the default behavior prior to 3.2.6, but has been turned off by default to try and improve stability. To enable this feature, check the box labeled Large Blob Count Enabled in the UI under the source advanced options. If you are using XML, add the following line, right below the source <connectString> element:

<largeBlobCountEnabled>true</largeBlobCountEnabled>

If you see extremely slow progress for a CAS migration, please verify that the IPs in the connection string are correct. If one of the IPs is wrong, this will cause CLIP_OPEN calls to take a very long time (1 minute+).

If you see an error similar to the following:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: 
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target

Your storage may be using an SSL certificate that is not trusted or well-known to Java. If so, you will need to add the certificate to the Java keystore on each ecs-sync VM.

These fields are not intended to be required. This is a documented bug in 3.1 that will be addressed in 3.1.1. The problem shows up when using Chrome, Internet Explorer, and Firefox browsers. To get around this show all advanced options fields and enter [space] into each of the empty fields. Doing this will allow the user to submit a new sync.

Skipped objects are a sign that and object has already been migrated (there is a row in the database that shows it has been successfully transferred or verified and the source object has not changed since that time). If you see this during the first run of a sync, you probably have duplicate entries in your source list file. Verify that your source list is "clean" by running sort -u [file] > [file].clean.

If you see the following error after upgrading to 3.2.5 and using XML on the command line, you need to add an encrypted password to your XML file.

java.sql.SQLException: Access denied for user 'ecssync'@'localhost' (using password: NO)

This is due to a bug, which is fixed in 3.2.6. To work around it, add the following line to the XML, right below the <dbTable> element:

<dbEncPassword>Z0TUQ+sciX2fp623Iu9LcQ==</dbEncPassword>

If you see the following error after upgrading to 3.2.9, you are using a database table that was created by a prior version.

com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'source_md5' in 'field list'

This version added a column to the database table to track the source MD5 checksum (this is mentioned in the release notes). After upgrading to this version, you need to either create a new DB table, or add the appropriate column by executing the following in a mysql shell:

alter table <table_name> add column source_md5 VARCHAR(32);

(where <table_name> is the name of your existing table).

If you see the following error while syncing an S3 bucket, there are object keys in the bucket with invalid characters:

org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 135069; An invalid XML character (Unicode: 0x3) was found in the element content of the document.

This means that, while listing the source bucket, an invalid character was encountered and processing could not continue. To resolve this, you must URL-encode the keys when listing the bucket. This feature is turned on by the following advanced option in the ECS S3 plugin (in the source config):
UI:

XML (place within the source <ecsS3Config> block):

    <urlEncodeKeys>true</urlEncodeKeys>