File Transfer Stuck at 100%: Check Verification and Finalization
A file transfer stuck at 100% may still be verifying or finalizing. Use logs, read traffic and an acceptance test to find the remaining work.
The transfer reaches 100%, the network graph falls quiet, and the editor asks whether the footage is ready. Before restarting the job, check what that percentage measures. It may count payload bytes while verification or the destination’s final operation is still running.
Start by separating three milestones: bytes sent, destination operation completed, and delivery accepted. The gap between them can explain a long wait without proving that the file is damaged or that the application has failed.
What real reports show
In a July 2026 Synology discussion, an rclone 1.74.3 user reported a pause after an encrypted copy to a mounted SMB share reached 100%. A posted log eventually recorded a matching checksum and completed copy; later replies described further testing.
That is a specific configuration and a useful lead, not evidence that every Synology or encrypted transfer has the same cause. The user’s later experiment disabling checksum verification changed the work being done. It does not establish an equivalent, verified delivery.
An older March 2026 report showed the opposite symptom: rclone 1.73.2/1.73.3 displayed 0% during a successful server-side S3 copy. A maintainer subsequently pointed to a beta fix. This is historical progress-reporting evidence, not a claim about current releases.
Both cases illustrate why a percentage needs context. The next step is to examine the operation behind it.
Identify the work that remains
A file transfer can include several operations that a byte counter does not represent well:
- Reading and sending the payload. This is usually the stage a throughput display makes easiest to see.
- Checking the destination. Verification may compare a server-provided hash or read file contents again.
- Completing the destination operation. A storage service may need to assemble uploaded parts, or a client may still be closing a file or applying metadata.
- Accepting the handoff. The recipient confirms the required files exist, verification passed, and the intended application can use them.
These stages may overlap, and implementations differ. Use logs to establish which applies instead of assuming that every pause is checksum work.
Amazon S3 provides a concrete finalization example. Its CompleteMultipartUpload documentation says completion can take minutes and an initial HTTP 200 can still be followed by an error in the response body. Check the client’s final result, not just uploaded parts or an initial response.
For a local or mounted path, also check the last metadata operation. The rclone local backend documentation describes modification-time updates after copying and possible permissions problems on CIFS mounts. A timestamp error calls for a different investigation from a long content read.
Use activity to narrow the cause
The following table is a diagnostic framework, not a list of confirmed causes for every application.
| What you observe | What it suggests | What to check next |
|---|---|---|
| Bytes show 100%, but completed-file count has not advanced | An operation for the current file remains open | Last log entry, verification status and destination response |
| Sender receives substantial data after upload stops | Possible destination readback for verification | Process/network counters and the backend’s hashing method |
| Destination disk or CPU stays active | Hashing, writes or another local operation may still be running | The responsible process and its logs |
| Multipart request remains pending | Server-side finalization may still be underway | Final API/client result and any returned error |
| Permission or timestamp errors repeat | Metadata processing or retry behavior | Destination ownership, permissions and the exact failed operation |
| No activity, no completed result and repeated timeouts | A stalled connection or retry loop is possible | Timeout/error history; preserve the log before retrying |
Low sender traffic alone cannot distinguish a healthy server-side operation from a stalled one. Likewise, a file appearing in a directory does not establish that it is complete. Look for a successful job result and the agreed verification outcome.
If the transfer is slow throughout rather than only at the end, begin with the upload bottleneck guide.
Where the checksum runs changes the cost
A checksum is a digest calculated from file contents. Comparing it is inexpensive once both values exist; obtaining it may require another full read.
A mounted SMB path can look local to the transfer application even though the bytes live on another machine. If verification reads that path, the read can cross the network again. Check the actual backend and configuration: rclone’s native SMB backend and its local backend pointed at a mounted share are different paths, so do not assume identical hashing behavior.
With rclone’s SFTP backend, a permitted remote shell command can calculate the hash on the destination. This can avoid bringing the destination file back over the network, but it still consumes destination read bandwidth and CPU. A restricted SFTP account may not permit those commands.
Choose that arrangement only when it fits the existing access policy. Granting broad shell access just to shorten a verification pass is a separate operational decision. For transfer-stage tuning, see the SFTP performance guide.
Budget for verification explicitly
Consider a modeled example, not a benchmark: one 100 GB decimal file, an effective payload rate of 100 MB/s, followed by one full verification read at 40 MB/s, with no overlap.
| Stage | Calculation | Time |
|---|---|---|
| Payload | 100,000 MB / 100 MB/s | 16 min 40 sec |
| Verification read | 100,000 MB / 40 MB/s | 41 min 40 sec |
| Combined | 1,000 + 2,500 seconds | 58 min 20 sec |
This excludes enumeration, other reads, retries and finalization. Cached reads, server-provided hashes, overlapping work or slower hardware change the result. Its purpose is to show why payload ETA can seriously understate the remaining delivery time.
Verify the copy without silently weakening the check
Keep the source stable until acceptance. For an existing rclone setup, choose a verification method that matches the backend:
- rclone check compares inventories, sizes and available compatible hashes. Check its output to see which checks were actually possible; matching sizes alone do not establish matching contents.
- rclone checksum compares a destination with a saved SUM manifest. Its download option can calculate hashes from remote content when necessary.
- rclone cryptcheck checks against an encrypted remote and requires hash support from the underlying storage. Account for its reads and encryption work.
If hashes are unavailable, rclone check’s --download mode reads contents for comparison. Budget the resulting network traffic and storage load before running it over a large remote collection.
Switching off checksums may make the progress display finish sooner because a check was removed. If you separate transfer and verification into scheduled jobs, record both outcomes; do not mark the package accepted while the verification job remains pending.
Set a useful completion rule
For the next representative delivery, record three times: when payload progress reaches its end, when the client reports successful completion, and when recipient verification finishes. Keep file count, total bytes, errors and the verification method alongside them. Change one configuration variable per test.
For camera originals, add a representative open or relink test after integrity verification. Our remote-footage handoff guide describes the inventory and acceptance process.
If the final wait grows with file size and readback activity, investigate verification placement and capacity. If it follows an explicit error, resolve that error. These observations provide a better basis for the next action than restarting a job each time its percentage stops moving.