juicedata/juicefs · error
status: %v, message: %s
Error message
status: %v, message: %s
What it means
parseResp reads the whole UFile response body and, when the HTTP status is not 200, returns the raw status code and body as an error. Callers of List, CreateMultipartUpload and ListUploads surface this whenever UFile rejects the request.
Source
Thrown at pkg/object/ufile.go:150
func (u *ufile) parseResp(resp *http.Response, out interface{}) error {
defer resp.Body.Close()
var data []byte
if resp.ContentLength <= 0 || resp.ContentLength > (1<<31) {
d, err := io.ReadAll(resp.Body)
if err != nil {
return err
}
data = d
} else {
data = make([]byte, resp.ContentLength)
if _, err := io.ReadFull(resp.Body, data); err != nil {
return err
}
}
if resp.StatusCode != 200 {
return fmt.Errorf("status: %v, message: %s", resp.StatusCode, string(data))
}
err := json.Unmarshal(data, out)
if err != nil {
return err
}
return nil
}
func copyObj(ctx context.Context, store ObjectStorage, dst, src string) error {
in, err := store.Get(ctx, src, 0, -1)
if err != nil {
return err
}
defer in.Close()
d, err := io.ReadAll(in)
if err != nil {
return err
}View on GitHub (pinned to c9a67b23e8)
Solutions
- Read the message body — it contains UFile's specific error reason
- Verify public/private API keys and the bucket's system/space configuration
- Re-sign with accurate timestamp; fix host clock skew (NTP)
- Retry on 5xx / rate-limit responses with backoff
Example fix
// before
// status: 401, message: {"ErrorCode":"Signature does not match"}
// after
// regenerate API key pair and update --access-key/--secret-key Defensive patterns
Strategy: try-catch
Try / catch
_, err := store.List(ctx, prefix, marker, limit, false)
if err != nil && strings.HasPrefix(err.Error(), "status:") {
var sc int
fmt.Sscanf(err.Error(), "status: %d", &sc)
switch sc { case 401, 403: /* fix keys */; case 429, 500: /* backoff-retry */ }
} Prevention
- Validate UFile public/private keys with a cheap List call first
- Keep host clocks synced (NTP) — signatures depend on timestamps
- Confirm the bucket belongs to the signing account/project
When it happens
Trigger: UFile API returns non-200: bad signature/credentials (401/403), bucket not found (404), malformed list request, expired token, or 5xx from the UFile service; body is returned verbatim in the message.
Common situations: Wrong UFile API private/public key pair; bucket name typo; system bucket mismatch with signature host; clock skew invalidating the UFile signature; rate limiting.
Understand the failure class
Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.
Related errors
- UploadPart: %s
- CompleteMultipart: %s
- ${errMsg}
- ceph: can't put empty file
- GOOGLE_CLOUD_PROJECT environment variable must be set
AI-assisted analysis of juicedata/juicefs@c9a67b23e8 (2026-09-06).
Data as JSON: /api/errors/13db34f6cc71f195.
Report an issue: GitHub.