Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
Rclone Keeps Retrying: Network or Remote Error?
Marcus Reid
October 7, 2026· 11 min read
When rclone keeps retrying, identify the first failed operation before increasing retry counts. A connection timeout, an authentication rejection, a provider rate limit, and a failed destination write need different responses; use a read-only listing and one isolated test file to separate them.
Key Takeaways:
- Preserve the first error, backend, command, version, and timestamp.
- High-level retries and low-level request retries are different mechanisms.
- Start with a narrow listing; copy only into an authorized test destination.
- A different route is relevant to connection failures, not expired credentials or exhausted storage.
Step 1: What happens when rclone keeps retrying?
Before changing rclone copy retries, stop the repeated job cleanly and record the complete command with private values removed. Note whether it is listing, downloading, uploading, checking, or running a larger scheduled workflow. “Retrying” describes behavior, not the underlying cause, and a final summary can hide the first useful error.
Record rclone version, operating system, configured backend type, source and destination roles, and the exact time. Preserve the first meaningful error from the existing output. Do not immediately enable HTTP body or authentication dumps: configuration and diagnostic output can reveal account identifiers, private filenames, and secrets.
Rclone distinguishes high-level retries of a failed operation from low-level retries of individual operations such as HTTP requests. Its documentation describes --retries and --low-level-retries separately.［1］ Several requests inside one copy can therefore produce many retry messages without representing many complete job restarts.
If a desktop cloud application is the actual client, use the cloud-sync direction checklist. This workflow covers rclone's command, backend, and operation, rather than resetting an unrelated desktop account or sync database.
If several unrelated applications also fail, start with the device and app baseline checks before changing this client.
Step 2: Which error branch should you follow?
Read the error closest to the failed request and compare it with the backend's documented behavior. An HTTP-based backend may expose status codes; an SFTP backend may instead report an SSH or file-operation error. Do not force every backend into an HTTP explanation.
| Observed evidence | Likely branch | Safe next action |
|---|---|---|
| Connection establishment times out | Network, proxy, endpoint | Compare one authorized path after checking configuration |
| Reads become idle after progress | Transfer path or service interruption | Record bytes and elapsed time; test a small file |
| Authentication or permission is rejected | Credentials or remote access | Resolve the named account or path condition |
| Provider reports 429 or a quota limit | Rate or allowance | Follow provider wait and quota instructions |
| Destination rejects a file operation | Permission, space, name, or backend behavior | Inspect the test destination before another write |
| Some operations succeed while others fail | Operation-specific scope | Compare the same failed operation, not a browser login |
The table narrows responsibility; it does not prove that a single status identifies the entire incident. Keep the backend name and exact operation with the error. An account login working in a browser does not prove that rclone's saved token, endpoint, or requested method is valid.
Use the connection-versus-read timeout explanation for the timing distinction, while taking rclone flag meanings from rclone itself. Its connection timeout concerns establishing the remote connection; its I/O idle timeout concerns a transfer that stops making progress.［1］
Step 3: Can a narrow read-only listing finish?
Choose a remote and path you already have permission to use. Substitute that actual configured name for remote:approved-test-parent; the example is a placeholder, not a ready-to-run account configuration. Confirm the backend before running any command.
rclone version
rclone lsd remote:approved-test-parent --max-depth 1
lsd lists directories and does not request file deletion or synchronization. The command documentation describes its directory listing and depth controls.［2］ A successful result with no directory rows can simply mean there are no subdirectories; an empty terminal output is not itself a failure.
This image typesets actual command output from a controlled local backend with non-sensitive files; it is not a captured desktop terminal window. It illustrates command structure and content verification only; it is not a cloud-backend test, a reproduction of your retry error, or an AethoVPN performance result.
Keep the output private when it contains directory names. If the listing fails immediately with an authorization error, resolve access before copying. If it succeeds, proceed with one test file instead of assuming that upload permissions, quota, and every object operation also work.
Step 4: Is an rclone connection timeout hidden by retry settings?
Inspect the flags in the existing command, its wrapper, and any approved environment configuration. Do not change several settings together. Rclone documents --contimeout as the connection timeout and --timeout as the I/O idle timeout; the latter is not a deadline for an entire healthy transfer.［1］
For one diagnostic listing, a limited attempt can make the first failure easier to inspect:
rclone lsd remote:approved-test-parent --max-depth 1 --retries 1 --low-level-retries 1
This deliberately limits rclone's diagnostic retries; it is not a new production policy or a promise that every backend interaction sends exactly one network request. Save the original command and use the bounded version only where the backend and administrator permit it. Stop when the result is clear instead of repeatedly invoking the “single attempt.”
Do not set timeouts to zero to make a hung job look persistent. Increasing a timeout may suit a documented slow service, but it cannot authenticate an expired token or create missing write permission. If the remote returns a rate-limit response, follow its documented wait and reduce unnecessary work rather than raising concurrency to escape the limit.
Step 5: Does a required proxy or remote policy explain it?
Determine whether the process runs on your computer, a VM, a container, or a remote server. Inspect proxy configuration in the environment where rclone actually executes. A VPN installed on your laptop does not establish that a scheduled process on another machine uses that laptop's route.
Rclone's HTTP-based services support proxy configuration, including standard proxy environment variables.［1］ A shell, scheduler, and desktop session can inherit different values. Check whether a required organization proxy is present, whether an obsolete value remains, and which proxy should handle the selected backend.
Do not print the whole environment or publish rclone.conf. Check only the relevant configuration locally, and hide credentials embedded in a proxy URL. For a managed network, ask its owner to confirm the supported route; do not remove an enforced proxy or substitute a personal service against policy.
For certificate failures, preserve the error and use the TLS warning checks. Keep verification enabled. For a WebDAV backend specifically, the browser-versus-WebDAV diagnosis separates endpoint and method issues from generic retries.
Step 6: Can one test copy complete without affecting real data?
Prepare a small, harmless text file in a separate local directory and choose a new, authorized remote test directory. Check the destination before copying so no valuable same-named file is present. Rclone copy copies source-directory contents and does not delete destination files, but that does not make it incapable of updating an existing file.［3］
rclone copy ./connection-test remote:approved-test-parent/unique-test-directory --transfers 1 --retries 1 --low-level-retries 1
The local source directory should contain only the intended test file. Do not replace it with a home directory, production backup root, or wildcard matching private files. The unique destination and single transfer keep the observation narrow; preserve those choices in every comparison.
Verify that the intended file arrived, then retrieve it to a different local verification directory or inspect its contents through an approved client. Compare the actual text with the original. A zero exit code or matching file size is useful evidence, but neither by itself proves that the expected content is present at the intended path.
Never substitute sync, delete, purge, or a cleanup command as part of this diagnosis. Do not use a live production destination simply because copy is non-deleting. Remove test data only through a separate, understood cleanup action after retaining the evidence you need.
Step 7: Does changing only the connection path alter the result?
Use this branch when the evidence identifies a connection failure, not a provider quota or an explicit account rejection. Keep the rclone process on the same device, with the same backend, credentials, command, test path, file, and transfer count. Where permitted, record one direct result and one alternative-route result.
On the supported Debian/Ubuntu x64 computer executing rclone, AethoVPN's official .deb client can supply the alternative outbound path; use Pro or Premium for desktop access. Enable global mode, choose a currently available position, and rerun the same bounded listing and isolated copy. A successful copy should be followed by content verification, while an expired backend token, 429 response, storage allowance, or rejected destination write remains the remote service's responsibility. Register to start a 3-day free Pro connection test; the once-per-user trial begins at registration.
For Windows, use the official Windows installer on the computer running rclone. On Mac, follow the website's configuration guide with Pro or Premium. Do not generalize the Linux package to unsupported distributions or architectures, and do not claim that a local client reroutes rclone running elsewhere.
If only the route changes and the same operation works, record that limited contrast at the stated time. If both paths return the same account or provider error, stop route changes. The file-transfer diagnosis covers size-dependent stalls; the VPN verification sequence establishes connection state without replacing rclone's own result.
Rclone skips files it considers identical at the destination.［3］ Inspect the actual transfer count and bytes for each attempt: a successful repeat with no file transferred does not validate the upload path. If the test file already exists, record the listing and skip outcome only; ask the destination owner for an approved isolated retransmission procedure before comparing uploads. Do not delete a partial or force an overwrite merely to manufacture a transfer.
Step 8: What evidence makes an escalation useful?
Send the client version, backend, operation, sanitized command, first error, time zone, retry settings, and listing/copy/content-verification outcomes. Distinguish a direct result, a changed-path result, and an untested condition. Do not summarize “works sometimes” when you can identify which operation and path differed.
Keep full logs and configuration private. Submit only reviewed excerpts through the provider's or administrator's approved channel. Do not send access tokens, passwords, private filenames, or file contents merely to prove that a connection failed.
Restore diagnostic flags to the documented operational policy after the investigation. A transient success is not proof that production retries should be permanently disabled, and a repeated failure is not a reason to increase them indefinitely. Resume larger jobs only after the small operation's outcome and the responsible correction are understood.
Summary
- Classify the first failure before changing retries.
- Verify one narrow listing and one isolated copy.
- Check the actual execution environment and proxy requirements.
- Compare routes only for a real network branch and verify destination contents.
FAQ
Why do retries continue after a small file starts uploading?
A file transfer can contain multiple low-level requests, and a larger operation can retry separately. Preserve the earliest meaningful error to distinguish those layers rather than counting console messages.［1］
Can increasing retries fix a 429 response?
More attempts do not expand the provider's allowance. Follow its rate-limit instructions and reduce unnecessary requests; do not increase parallel transfers to bypass the wait.
Does copy guarantee that existing destination files remain unchanged?
copy does not delete destination files, but it may update matching paths. Use a new test directory and inspect it before writing so a non-deleting command cannot overwrite valuable content.［3］
Why does a browser work while rclone fails?
The browser may use another session, endpoint, proxy, or request method. Check the rclone backend and its own first error before concluding that its connection or credentials are valid.
Does an empty lsd result mean the remote is broken?
A successful listing can be empty when the path has no subdirectories. Check the exit result and intended directory; absence of rows is not the same as an error.［2］
Should I publish my configuration to get support?
Keep configuration and tokens private. Provide a sanitized command and reviewed error excerpt through an approved channel; public access to your remote is not necessary for first-stage diagnosis.
Will a laptop VPN change a server's scheduled rclone job?
A client installed on your laptop does not prove coverage of a process on another server. Test and configure the network in the environment where that process actually runs.
Disclaimer: Use only authorized remotes and test destinations. Preserve original files and provider limits; the examples do not authorize deleting data, bypassing access policy, or disabling certificate verification.
Sources
- Rclone — Documentation — https://rclone.org/docs/
- Rclone — rclone lsd — https://rclone.org/commands/rclone_lsd/
- Rclone — rclone copy — https://rclone.org/commands/rclone_copy/
Sources checked 7 October 2026.
