What causes "Failed to get: %s" in juicedata/juicefs?

Check IAM/bucket policy for s3:GetObject deny on the principal

Failed to get: %s

Error message

Failed to get: %s

What it means

The verification read (Get) of the test object failed after the Put succeeded. JuiceFS writes a test object during format and reads it back to prove the store is usable end-to-end; a failure here means the backend cannot serve reads even though writes appear to work.

Source

Thrown at cmd/format.go:358

			if strings.Contains(err.Error(), "NoSuchBucket") {
				return fmt.Errorf("Failed to create bucket %s: %s, previous error: %s\nPlease create bucket %s manually, then format again.",
					store, err2, err, store)
			} else {
				return fmt.Errorf("Failed to create bucket %s: %s, previous error: %s",
					store, err2, err)
			}
		}
		if err := store.Put(ctx, key, bytes.NewReader(data)); err != nil {
			return fmt.Errorf("Failed to put: %s", err)
		}
	}
	// GLACIER storage class doesn't allow read after write
	if _, ok := ctx.Value(object.TierKey{}).(uint8); ok {
		return nil
	}
	p, err := store.Get(ctx, key, 0, -1)
	if err != nil {
		return fmt.Errorf("Failed to get: %s", err)
	}
	data2, err := io.ReadAll(p)
	_ = p.Close()
	if err != nil {
		return err
	}
	if !bytes.Equal(data, data2) {
		return fmt.Errorf("read wrong data: expected %x, got %x", data, data2)
	}
	err = store.Delete(ctx, key)
	if err != nil {
		// it's OK to don't have delete permission, but we should warn user explicitly
		logger.Warnf("Failed to delete, err: %s", err)
	}
	return nil
}

func test(ctx context.Context, store object.ObjectStorage) error {

View on GitHub (pinned to c9a67b23e8)

Solutions

Check IAM/bucket policy for s3:GetObject deny on the principal
Verify the storage class isn't archival (Glacier requires restore before read) — or set the appropriate --storage-class/tier
If using SSE-KMS, ensure the key policy permits Decrypt for the principal
Retry format; if transient consistency lag, the second attempt usually passes

Example fix

// before
{"Effect":"Allow","Action":"s3:PutObject","Resource":"arn:aws:s3:::b/*"}  // no GetObject
// after
{"Effect":"Allow","Action":["s3:PutObject","s3:GetObject"],"Resource":"arn:aws:s3:::b/*"}

Defensive patterns

Strategy: try-catch

Validate before calling

// verify read access after writing
// aws s3api get-object --bucket mybucket --key t /dev/null

Try / catch

err := doTesting(ctx, store, key, data)
if err != nil && strings.Contains(err.Error(), "Failed to get") {
    // check GetObject permissions, storage class, KMS decrypt grants
}

Prevention

Grant s3:GetObject alongside s3:PutObject
Avoid archival storage classes (Glacier) for the metadata/test path
With SSE-KMS, allow Decrypt in the key policy
Bypass caches/proxies that may break read-after-write

When it happens

Trigger: `juicefs format` where Put succeeds but Get errors — eventual-consistency lag on some S3-compatible stores, GetObject denied by policy, GLACIER/DEEP_ARCHIVE storage classes requiring restoration (handled separately via TierKey), or KMS key policy denying decrypt.

Common situations: Read-only IAM policies that oddly permit Put via a different path; SSE-KMS keys where the principal can encrypt but not decrypt; minio/Swift eventual consistency quirks; storage-class restrictions like Glacier instant retrieval misconfig.

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/10007d17c521e0f6. Report an issue: GitHub.