juicedata/juicefs · error

Decrypt: %s

Error message

Decrypt: %s

What it means

After slicing a valid chunk, the chunked reader decrypts chunk[header:header+ctLen] via the underlying dataEncryptor. Failures (bad key, corrupted AEAD data, wrong nonce) are wrapped as 'Decrypt: %s'.

Source

Thrown at pkg/object/encrypt_chunked.go:169

	}()

	n, err := io.ReadFull(r.r, *chunkBuf)
	chunk := (*chunkBuf)[:n]
	if err != io.ErrUnexpectedEOF && err != nil {
		return 0, err
	}

	if len(chunk) < chunkHeaderSize {
		return 0, fmt.Errorf("Decrypt: truncated chunk header")
	}
	ctLen := int(binary.BigEndian.Uint32(chunk[:chunkHeaderSize]))
	if chunkHeaderSize+ctLen > len(chunk) {
		return 0, fmt.Errorf("Decrypt: chunk data truncated: need %d, have %d", chunkHeaderSize+ctLen, len(chunk))
	}

	plain, decErr := r.enc.Decrypt(chunk[chunkHeaderSize : chunkHeaderSize+ctLen])
	if decErr != nil {
		return 0, fmt.Errorf("Decrypt: %s", decErr)
	}

	if r.skip > 0 {
		skip := r.skip
		r.skip = 0
		if skip >= int64(len(plain)) {
			return 0, io.EOF
		}
		plain = plain[skip:]
	}

	n = copy(p, plain)
	if n < len(plain) {
		r.buf = plain[n:]
		r.chunkBuf = chunkBuf
	}
	return n, nil
}

View on GitHub (pinned to c9a67b23e8)

Solutions

1. Remount using the original encrypt key from volume format; AEAD auth failures almost always mean key mismatch
2. Locate the corrupt object via logs and restore/re-sync it from a healthy source
3. Re-run juicefs fsck/gc style checks and repair from replicas where available
4. Ensure all clients for the volume use identical encryption settings (key file and algo)

Example fix

// before
juicefs mount --encrypt-algo chacha20-rsa --encrypt-key k2.pem ...
// after: match the format-time configuration
juicefs mount --encrypt-algo aes256gcm-rsa --encrypt-key k1.pem ...

// mount-time check: encrypt a canary object then read it back
// failure here means wrong key/corrupt chunk — fail fast before serving traffic

n, err := r.Read(buf)
if err != nil && strings.HasPrefix(err.Error(), "Decrypt: ") {
	// AEAD auth failed: wrong encrypt key or corrupted chunk
}

When it happens

Trigger: Calling Read on a chunked encrypted object whose chunk payload fails AEAD verification — typically because the volume is mounted with a different RSA key than at format time, or the chunk bytes were altered/corrupted.

Common situations: Wrong --encrypt-key on mount; storage-level bit rot or partial restore; mixing objects written under different encryption configurations; tampered objects in a shared bucket.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

• Decrypt: %s
• open cipher: %s
• received encrypted text length is less than 3, the object is
• malformed ciphertext: %d %d
• Decrypt: truncated chunk header

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