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

  1. Read the message body — it contains UFile's specific error reason
  2. Verify public/private API keys and the bucket's system/space configuration
  3. Re-sign with accurate timestamp; fix host clock skew (NTP)
  4. 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

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


AI-assisted analysis of juicedata/juicefs@c9a67b23e8 (2026-09-06). Data as JSON: /api/errors/13db34f6cc71f195. Report an issue: GitHub.