What causes "up status: %d, error: %s" in AlistGo/alist?

Read the XML body in the error message — it names the exact S3 error (InvalidPart, EntityTooSmall, NoSuchUpload)

up status: %d, error: %s

Error message

up status: %d, error: %s

What it means

Raised in Cloudreve's S3 upload finalization. After all chunks are PUT, the driver issues the complete-multipart-upload request (XML body) to S3; a non-200 response aborts with this message including the HTTP status and the raw response body, which contains S3's XML error details.

Source

Thrown at drivers/cloudreve/util.go:453

	bodyBuilder.WriteString("</CompleteMultipartUpload>")
	req, err := http.NewRequest(
		"POST",
		u.CompleteURL,
		strings.NewReader(bodyBuilder.String()),
	)
	if err != nil {
		return err
	}
	req.Header.Set("Content-Type", "application/xml")
	req.Header.Set("User-Agent", d.getUA())
	res, err := base.HttpClient.Do(req)
	if err != nil {
		return err
	}
	defer res.Body.Close()
	if res.StatusCode != http.StatusOK {
		body, _ := io.ReadAll(res.Body)
		return fmt.Errorf("up status: %d, error: %s", res.StatusCode, string(body))
	}

	// 上传成功发送回调请求
	err = d.request(http.MethodGet, "/callback/s3/"+u.SessionID, nil, nil)
	if err != nil {
		return err
	}
	return nil
}

View on GitHub (pinned to 843d9dc814)

Solutions

Read the XML body in the error message — it names the exact S3 error (InvalidPart, EntityTooSmall, NoSuchUpload)
Restart the upload from scratch so the part list and ETags stay consistent
Ensure all parts except the last are at least 5 MiB (raise chunk size if needed)
Verify the server's S3 configuration and session validity

Defensive patterns

Strategy: try-catch

Validate before calling

// pre-flight: verify all part ETags were collected and parts meet size rules before completing
if len(etags) != expectedPartCount {
    return fmt.Errorf("part count %d != expected %d; aborting complete", len(etags), expectedPartCount)
}

Try / catch

if err := d.completeS3Upload(...); err != nil {
    if strings.Contains(err.Error(), "up status:") {
        // parse the XML body for InvalidPart/EntityTooSmall/NoSuchUpload and decide:
        // NoSuchUpload/InvalidPart -> restart the whole upload; EntityTooSmall -> bigger chunks
    }
}

Prevention

Record every part's ETag in order and validate the list before sending complete
Ensure non-terminal parts are at least 5 MiB
Never reuse a multipart session after a mid-upload error; restart cleanly

When it happens

Trigger: Completing the multipart upload when S3 rejects the request: missing or mismatched parts (a chunk PUT silently failed or was retried after the part list diverged), entity-too-small last part, expired session, or invalid part-order — S3 returns 400 with an XML error that lands verbatim in this message.

Common situations: A mid-upload retry desynchronized the ETag/part list sent in the complete request; uploading a final chunk smaller than S3's minimum part size (5 MiB) for non-terminal parts; S3-compatible backends with stricter complete semantics.

Related errors

AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15). Data as JSON: /api/errors/d9c326c6df3dffb0. Report an issue: GitHub.