Troubleshooting Sync

Files.com records a message against every file a sync run fails on, and those per-file messages are what identify the cause. Start there rather than with the status of the run, because a partial failure can contain different causes for different files.

Most sync failures are explained on the page for the behavior that produced them. A file skipped for changing mid-run is covered under determining when to sync a file, folders omitted for colliding on case under filename requirements, and files a remote server refuses outright under file size limitations. The failures below need diagnosis across more than one of those causes.

Connection Is Lost or Is Unresponsive

The error Connection is lost or is unresponsive, please try again. means something on the remote server took too long to respond. It appears on the failed operation of a run that ends in Failure or Partial Failure, often a List operation, and begins with the ID, type, and name of the Remote Server used by the sync.

A target folder too large to list produces this error. Every sync compares the source files with the destination files, including the metadata you would see in a folder listing, so a wide and deep folder structure takes a long time to list recursively. A listing that takes more than a few minutes is problematic. Point the sync at a smaller target folder, split the work across multiple syncs each covering a smaller subfolder, or reduce the number of items in the folder.

It also appears when a single file takes longer to transfer than the remote server's connection timeout allows. An indicator of this is one file failing on every run while the rest of the sync succeeds. Ask the administrator of the remote server to allow a longer connection duration, or reduce the file sizes so each file fits inside the duration the server allows.

Local File or Folder Not Found

The error Local file/folder not found: followed by the name of the item means the item disappeared after the run started but before the run reached it. Something deleted, moved, or renamed it in between.

A sync builds its list of names first and then works through that list, so an item renamed partway through a run cannot be found under the name that was recorded. The next run picks the file up under its new name, as long as nothing renames, moves, or deletes it again.

A handful of these errors on a run that otherwise succeeds is the normal result of a busy source folder. When they arrive in bulk, or the affected files change from run to run, another process is competing for the same location. A run may also report that the destination already exists, which happens when another job writes the same destination path first and Files.com declines to overwrite what is already there. Other times a run skips files with no warning at all.

Concurrent Access covers which overlaps cause this and how to separate two jobs that have to use the same location.

Failures That Repeat on the Same Files

When the same files fail on every run and the logs record the same message each time, the cause is a fixed obstacle rather than a passing one. Check the file sizes the remote server accepts, the filename requirements on both sides, the permissions the sync account holds, and the credentials and IP allowlisting the remote server requires. When only one file fails this way, it may instead be hitting the connection timeout.

Identify the failed operation and path in the Sync log and the Outbound Connections log. A failed listing, download, upload, replacement, or source deletion needs different permissions. Ask the remote administrator to check that operation for the connection’s actual account, rather than granting full access to both sides.

If a test is needed, use a separate Sync with External Trigger, a small completed sample, an isolated destination, and After Copying set to keep. Verify the actual host, credentials, and paths; run Dry run before a manual transfer. An isolated destination can still replace its existing files, so use a new sample name and keep it outside application pickup paths. Test replacement or deletion separately on disposable samples only when that is the failed operation.

A successful test establishes only the operations and paths it exercised. Success in another folder does not prove access to the original folder. Compare the remote account’s rights on the failed path, make the required correction, and verify that operation with an agreed sample before restoring the production schedule.