What is the problem you are having with rclone?
When uploading a large file from a local or NFS-mounted source to S3, rclone
performs a full checksum pass over the entire source file before initiating the
multipart upload. During this pass:
- The `-vv` log goes completely silent -- zero log output is produced
- The progress display shows `0 B / 0 B` with no explanation
- No S3 API calls are made (confirmed via `rclone backend list-multipart-uploads`)
- No network traffic reaches S3 (confirmed via nload on the ISP interface)
- NFS traffic is sustained at full link speed (~1.5-2 Gbps on a 10GbE link)
For a 393 GiB file over a 10GbE NFS link, this pre-transfer phase lasts
approximately 30 minutes (storage media limit; network can handle more throughput). During this entire period, rclone appears completely
stalled from the user's perspective. The `-vv` log is silent and the progress
display gives no indication that any work is in progress.
**The problem is not the checksum itself -- it is the total absence of any
log output or progress indication during the checksum pass.**
A user seeing this behavior has no way to determine whether rclone is:
- Computing a checksum (working correctly)
- Hung waiting for a network response
- Deadlocked internally
- Stalled for any other reason
The only way to distinguish a working rclone from a hung one during this phase
is to monitor NFS traffic externally with a tool like nload.
**Workaround:** `--s3-disable-checksum` skips the pre-transfer checksum pass
entirely. With this flag, the multipart upload initiates within seconds and
both the -vv log and nload show immediate activity. Our use case makes this
safe because we generate and upload SHA-256 sidecar files independently for
restore validation.
**Evidence:**
Without `--s3-disable-checksum` (30-minute silent stall before upload begins):
21:14:48 - rclone starts
21:14:48 - "multi-thread copy: disabling buffering because source is local disk"
[30 minutes of silence -- zero log output, zero S3 traffic, ~393 GiB NFS reads]
21:44:41 - "size: 393.393Gi, parts: 10000, default: 5Mi, new: 41Mi; default chunk size insufficient, returned new chunk size"
21:44:41 - multipart upload initiated
21:44:41 - "Starting multi-thread copy with 9826 chunks of size 41Mi with 4 parallel streams"
With `--s3-disable-checksum` (immediate upload):
21:58:00 - rclone starts
21:58:00 - "multi-thread copy: disabling buffering because source is local disk"
21:58:00 - "size: 393.393Gi, parts: 10000, default: 5Mi, new: 41Mi; default chunk size insufficient, returned new chunk size"
21:58:00 - multipart upload initiated
21:58:00 - "Starting multi-thread copy with 9826 chunks of size 41Mi with 4 parallel streams"
The fix requested is simple: add a log line when the pre-transfer checksum pass
begins and ends, e.g.:
DEBUG : largefile.vbk: computing pre-transfer checksum (393.393 GiB source)...
DEBUG : largefile.vbk: pre-transfer checksum complete
This would make the behavior transparent and allow users to distinguish a
working rclone from a hung one without needing external network monitoring
tools.
Observed on rclone v1.73.2 and v1.73.3 with identical behavior.
Run the command 'rclone version' and share the full output of the command.
rclone v1.73.3
- os/version: ubuntu 24.04 (64 bit)
- os/kernel: 6.8.0-106-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.25.8
- go/linking: static
- go/tags: none
Which cloud storage system are you using? (eg Google Drive)
AWS S3
Source: NFS mount (NFSv4, read-only, rsize=1048576, noauto) at /mnt/nas_backup
File size: 393.393 GiB (422,402,543,616 bytes)
The command you were trying to run (eg rclone copy /tmp remote:tmp)
Command that triggers the silent stall (no --s3-disable-checksum):
rclone copyto \
"/mnt/nas_backup/backups/largefile.vbk" \
"s3remote:mybucket/backups/largefile.vbk" \
--config /home/user/.config/rclone/rclone.conf \
-P -vv \
--log-file /tmp/rclone_upload.log
Command with workaround (--s3-disable-checksum eliminates the silent stall):
rclone copyto \
"/mnt/nas_backup/backups/largefile.vbk" \
"s3remote:mybucket/backups/largefile.vbk" \
--config /home/user/.config/rclone/rclone.conf \
--s3-disable-checksum \
-P -vv \
--log-file /tmp/rclone_upload_nochecksum.log
With --s3-disable-checksum, the multipart upload initiates at t=0 and both
-vv log and network traffic show immediate activity.
The rclone config contents with secrets removed.
[s3remote]
type = s3
provider = AWS
access_key_id = <REDACTED>
secret_access_key = <REDACTED>
region = us-east-1
server_side_encryption = AES256
A log from the command with the -vv flag
**Without --s3-disable-checksum** (shows 30-minute silent gap):
2026/03/24 13:14:48 DEBUG : rclone: Version "v1.73.3" starting with parameters ["rclone" "copyto" "/mnt/nas_backup/backups/largefile.vbk" "s3remote:mybucket/backups/largefile.vbk" "--config" "/home/user/.config/rclone/rclone.conf" "-P" "-vv" "--log-file" "/tmp/rclone_upload.log"]
2026/03/24 13:14:48 DEBUG : Creating backend with remote "/mnt/nas_backup/backups/largefile.vbk"
2026/03/24 13:14:48 DEBUG : Using config file from "/home/user/.config/rclone/rclone.conf"
2026/03/24 13:14:48 DEBUG : largefile.vbk: Need to transfer - File not found at Destination
2026/03/24 13:14:48 DEBUG : largefile.vbk: multi-thread copy: disabling buffering because source is local disk
[*** 30 minutes of complete silence -- no log output at all ***]
[*** nload confirms ~393 GiB read from NFS during this period ***]
[*** nload confirms zero outbound S3 traffic during this period ***]
[*** rclone backend list-multipart-uploads returns empty during this period ***]
[*** progress display shows "0 B / 0 B" -- no indication of activity ***]
2026/03/24 13:44:41 DEBUG : largefile.vbk: size: 393.393Gi, parts: 10000, default: 5Mi, new: 41Mi; default chunk size insufficient, returned new chunk size
2026/03/24 13:44:41 DEBUG : largefile_dest.vbk: open chunk writer: started multipart upload: <UPLOAD_ID_REDACTED>
2026/03/24 13:44:41 DEBUG : largefile.vbk: Starting multi-thread copy with 9826 chunks of size 41Mi with 4 parallel streams
2026/03/24 13:44:41 DEBUG : largefile.vbk: multi-thread copy: chunk 1/9826 (0-42991616) size 41Mi starting
[... upload proceeds normally ...]
**With --s3-disable-checksum** (immediate upload, no stall):
2026/03/24 21:58:00 DEBUG : rclone: Version "v1.73.3" starting with parameters ["rclone" "copyto" "/mnt/nas_backup/backups/largefile.vbk" "s3remote:mybucket/backups/largefile.vbk" "--config" "/home/user/.config/rclone/rclone.conf" "--s3-disable-checksum" "-P" "-vv" "--log-file" "/tmp/rclone_upload_nochecksum.log"]
2026/03/24 21:58:00 DEBUG : Creating backend with remote "/mnt/nas_backup/backups/largefile.vbk"
2026/03/24 21:58:00 DEBUG : Using config file from "/home/user/.config/rclone/rclone.conf"
2026/03/24 21:58:00 DEBUG : largefile.vbk: Need to transfer - File not found at Destination
2026/03/24 21:58:00 DEBUG : largefile.vbk: multi-thread copy: disabling buffering because source is local disk
2026/03/24 21:58:00 DEBUG : largefile.vbk: size: 393.393Gi, parts: 10000, default: 5Mi, new: 41Mi; default chunk size insufficient, returned new chunk size
2026/03/24 21:58:00 DEBUG : largefile_dest.vbk: open chunk writer: started multipart upload: <UPLOAD_ID_REDACTED>
2026/03/24 21:58:00 DEBUG : largefile.vbk: Starting multi-thread copy with 9826 chunks of size 41Mi with 4 parallel streams
2026/03/24 21:58:00 DEBUG : largefile.vbk: multi-thread copy: chunk 1/9826 (0-42991616) size 41Mi starting
[... upload proceeds immediately ...]
The contrast is clear: without --s3-disable-checksum, the log goes silent for
30 minutes between "disabling buffering" and "size: 393.393Gi". With
--s3-disable-checksum, all four lines appear at the same timestamp.
**Progress display during the silent stall:**
Transferred: 0 B / 0 B, -, 0 B/s, ETA -
Transferred: 0 / 1, 0%
Elapsed time: 24m52.3s
Transferring:
* largefile.vbk: transferring
Note: `0 B / 0 B` -- rclone does not even display the file size during the
checksum pass, so the user cannot tell how large the file is or how long
the checksum will take.