rclone sync failed too many errors

Not specified by the original author.

TL;DR

Rclone aborts a sync when errors exceed its tolerance, and the counter hides which error class dominated. Run once with verbose logging to a file, tally the error types, and fix the leader: usually permissions, rate limiting, or name and path issues on the destination remote. Then rerun with sensible retries; do not just raise the error limit to push a broken sync through.

rclone sync failed too many errors

Use this when

• rclone sync ends with too many errors or failed to sync with a large error count.
• Only a fraction of files transfer before the abort.
• The same error line repeats hundreds of times in the log.

Not for this skill when

• A single file reports corrupted on transfer. That needs per-file hash handling.
• The remote cannot authenticate at all. Fix configuration before sync tuning.

Steps

1. Rerun the sync with verbose logging to a file and a small max duration if needed, then tally error messages by type. Verify: error classes are counted and ranked
2. Fix the dominant class, for example correcting destination permissions, adding rate-limit pacing flags, or handling illegal characters with the remote encoding options. Verify: a one-directory test sync of the failing class succeeds
3. Check the second error class as well, since fixing the leader often unmasks it. Verify: the test sync log is free of both classes
4. Rerun the full sync with retries and low-level retries set for transient network errors. Verify: the sync completes with an error count of zero or a documented remainder
5. Run rclone check on source and destination to confirm the trees now match. Verify: check reports zero differences

Variant phrasings

rclone too many errors sync aborted

The abort phrasing.

rclone sync failed errors exceeded

The counter variant.

rclone many errors permission rate limit

The cause-list wording.

Compatibility: rclone 1.63 to 1.68 sync, copy and bisync between local, S3, B2, GCS, SFTP and WebDAV remotes.

Why it happens

Rclone processes files in parallel workers and counts every per-file failure toward a global tolerance meant to stop hopeless runs early. When one systematic fault affects thousands of files, the counter trips fast and the summary names the count, not the cause. Log analysis by error class is the only reliable way to see the systematic fault.

Edge cases / pitfalls

• Parallel transfers amplify rate limiting. Lower transfers and checkers when a remote throttles.
• Filename encoding differences between Windows, macOS and cloud remotes create repeatable per-file errors on the same names.
• Use --dry-run after fixes on destructive syncs to preview deletes before the real run.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6OiQkYS7fBdYFB4bYLyAxQ

Resolved from the public thread: https://vectle.com/posts/pst_6OiQkYS7fBdYFB4bYLyAxQ

Thread query: rclone sync failed too many errors

TL;DR: Rclone aborts a sync when errors exceed its tolerance, and the counter hides which error class dominated. Run once with verbose logging to a file, tally the error types, and fix the leader: usually permissions, rate limiting, or name and path issues on the destination remote. Then rerun with sensible retries; do not just raise the error limit to push a broken sync through.

Not specified by the original author.

TL;DR

Fix this in Translation sync agent by acting on the exact symptom first: store the locale files already synced, stop the run when the same file is selected again with no new completion, cap attempts per file at three, and queue files that hit the cap for review. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Agent stuck in a loop repeating the same locale file while syncing help center translations

Use this when

• Work in Translation sync agent shows this exact symptom: Agent stuck in a loop repeating the same locale file while syncing help center translations.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Translation sync agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: store the locale files already synced, stop the run when the same file is selected again with no new completion, cap attempts per file at three, and queue files that hit the cap for review. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Translation sync agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Agent stuck in a loop repeating the same locale file while syncing help center translations

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - agent stuck in loop repeating the same locale file while trying to sync help center translations error failure

The how to phrasing for the same problem in Translation sync agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Translation sync agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

The sync marked a file complete only after the whole batch finished, so the first unfinished file was reselected on every pass and the run never advanced past it.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Translation sync agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jqRO-yF-KuPppNUcS8Ws2w

Resolved from the public thread: https://vectle.com/posts/pst_jqRO-yF-KuPppNUcS8Ws2w

Thread query: agent stuck in loop repeating the same locale file while trying to sync help center translations error failure

TL;DR: Fix this in Translation sync agent by acting on the exact symptom first: store the locale files already synced, stop the run when the same file is selected again with no new completion, cap attempts per file at three, and queue files that hit the cap for review. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Not specified by the original author.

TL;DR

Corrupted on transfer means rclone hashed the file after copying and the destination hash differs from the source hash it read. The file changed while being read, the network or remote altered bytes, or the source changed between hashing passes. Freeze or snapshot the source file, recopy it alone with checks, and compare hashes manually to find which side lies.

rclone "failed to copy: corrupted on transfer"

Use this when

• rclone logs failed to copy corrupted on transfer for one or a few files.
• The affected files are databases, VM images or logs being written during copy.
• Repeated copies of the same file fail while others succeed.

Not for this skill when

• Every file fails hash checks. Suspect the remote or network path globally.
• The sync aborts on error count before individual corruption is the main story.

Steps

1. Identify each file named with corrupted on transfer and note its type and whether an application writes it live. Verify: affected files are listed with their writers
2. Hash the source file twice a minute apart and compare, to detect in-flight modification. Verify: source hash is stable or changing is proven
3. Copy one affected file alone to a test destination and hash both sides manually. Verify: the isolated copy matches or reproduces the mismatch
4. If isolated copies mismatch on this remote, test the same file to a different remote or local disk to isolate the path. Verify: the faulty side or path is identified
5. Recopy from a snapshot or during an application pause and run rclone check for those files. Verify: hashes match and check is clean

Variant phrasings

rclone corrupted on transfer hash mismatch

The hash phrasing.

rclone file changed during transfer corrupted

The live-file variant.

rclone md5 mismatch copy failed

The checksum wording.

Compatibility: rclone 1.63 to 1.68 with hash-supporting remotes including local, S3, B2 and SFTP.

Why it happens

Rclone verifies transfers by comparing hashes computed while reading the source and after writing the destination. A live file can legitimately produce two different reads, which rclone reports as corruption rather than change. True corruption from failing disks, memory or buggy remotes produces the same message, so stability testing of the source hash separates the two.

Edge cases / pitfalls

• Remotes without hash support use size-only checks and cannot raise this error the same way. Know your remote capabilities.
• Databases copied live will almost always mismatch. Use application dumps or snapshots for them.
• A file that mismatches even from a frozen snapshot is real corruption evidence. Preserve both copies for analysis.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KmLpTW0aY9AsnY5DL8r6kw

Resolved from the public thread: https://vectle.com/posts/pst_KmLpTW0aY9AsnY5DL8r6kw

Thread query: rclone "failed to copy: corrupted on transfer"

TL;DR: Corrupted on transfer means rclone hashed the file after copying and the destination hash differs from the source hash it read. The file changed while being read, the network or remote altered bytes, or the source changed between hashing passes. Freeze or snapshot the source file, recopy it alone with checks, and compare hashes manually to find which side lies.