Bisync: Failed to upload chunk 1 with 5242880 bytes: NoSuchUpload

What is the problem you are having with rclone?

I am using Bisync and in other threads I have been getting help dealing with the constant errors it generates throughout the day when I am actively developing or moving files and folders in my local (errors without recover, with recover: one system online >> bisync successful >> winner cannot be determined) but this is new, and --recover or --re-scync do not resolve it:

2024/09/05 16:10:49 DEBUG : Got 149254 results for resync
2024/09/05 16:10:49 DEBUG : Lock file removed: /home/salty/.cache/rclone/bisync/idrive-sync-hasher_..local__home_salty_sync.lck
2024/09/05 16:10:49 ERROR : Bisync critical error: failed to upload chunk 1 with 5242880 bytes: NoSuchUpload: The specified multipart upload does not exist. The upload ID may be invalid, or the upload may have been aborted or completed.
        status code: 404, request id: 17F260695E436A61, host id: 
2024/09/05 16:10:49 ERROR : Bisync aborted. Must run --resync to recover.
Transferred:           20 MiB / 20 MiB, 100%, 0 B/s, ETA 0s
Errors:                 1 (retrying may help)
Checks:             59249 / 59249, 100%

rclone v1.67.0

  • os/version: ubuntu 22.04 (64 bit)
  • os/kernel: 5.15.0-119-generic (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.22.4
  • go/linking: static
  • go/tags: none

IDrive S3

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone bisync "idrive-sync-hasher:/" "/home/salty/sync/" --check-access --fast-list --verbose --filter-from=/home/salty/.config/rclone/filters --links --compare size,modtime,checksum --error-on-no-transfer --conflict-resolve newer --resilient --recover --resync -vP

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[idrive-sync]
type = s3
provider = IDrive
access_key_id = XXX
secret_access_key = XXX
acl = private
endpoint = x3k6.ie.idrivee2-50.com
bucket_acl = private
no_check_bucket = true
server_side_encryption = aws:kms

[idrive-sync-crypt]
type = crypt
remote = idrive-sync:sync
password = XXX
password2 = XXX
filename_encoding = base32768

[idrive-sync-hasher]
type = hasher
remote = idrive-sync-crypt:
hashes = md5
max_age = 3M
auto_size = 107374182400

A log from the command that you were trying to run with the -vv flag

My local contains filenames with personal information and it takes a lot of time for me to anonymise a log and check it, which I can do again if necessary but in case not here are the last few lines

2024/09/05 16:10:49 DEBUG : result: 
{
        "Src": "local{b6816}:/home/salty/sync/",
        "Dst": "idrive-sync-hasher:/",
	"Name": "cursor bak/.cursor/extensions/ms-python.vscode-pylance-2024.8.1/dist/typeshed-fallback/stubs/workalendar/workalendar/europe/scotland/mixins/victoria_day.pyi",
	"AltName": "",
	"Size": 429,
	"Modtime": "2024-08-28T21:41:36.493432471Z",
	"Hash": "6f5afce7da5ea2ae245cd798306b9b03",
	"Flags": "-",
	"Sigil": 61,
	"Err": null,
	"Winner": {
		"Obj": null,
		"Side": "dst",
		"Err": null
	},
	"IsWinner": false,
	"IsSrc": true,
	"IsDst": false,
	"Origin": "sync"
}
2024/09/05 16:10:49 DEBUG : result: 
{
        "Src": "local{b6816}:/home/salty/sync/",
        "Dst": "idrive-sync-hasher:/",
	"Name": "cursor bak/.cursor/extensions/ms-python.vscode-pylance-2024.8.1/dist/typeshed-fallback/stubs/workalendar/workalendar/europe/scotland/mixins/victoria_day.pyi",
	"AltName": "",
	"Size": 429,
	"Modtime": "2024-08-28T21:41:36.493432471Z",
	"Hash": "6f5afce7da5ea2ae245cd798306b9b03",
	"Flags": "-",
	"Sigil": 61,
	"Err": null,
	"Winner": {
		"Obj": null,
		"Side": "dst",
		"Err": null
	},
	"IsWinner": true,
	"IsSrc": false,
	"IsDst": true,
	"Origin": "sync"
}

The issue seemed to occur after I moved some directoris from different parts of my home directory into cursor bak on my local. How can I reslove this?

Is it possible that you moved the directories in the middle of a multipart upload that hadn't yet completed?

The error above suggests it is most likely an issue specific to s3 (as opposed to bisync), likely involving multipart uploads. The error message originates here.

It would also be worth trying with the latest version. (v1.68.0)

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.