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 usually has several unrelated causes at once.

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.

To confirm a permission is the cause, configure a second connection to the remote server using credentials that hold full access, and run the sync against that. If the sync succeeds, a permission on the original credentials is the cause.