What causes "unable to hash file %q downloaded: %v" in kubernetes/kops?

Re-run the copy; this is not a content problem and is usually transient or environmental.

unable to hash file %q downloaded: %v

Error message

unable to hash file %q downloaded: %v

What it means

After downloading the source asset into memory, transferFile hashes it with the declared algorithm (shaHash.Algorithm.Hash(bytes.NewReader(data))). If hashing itself errors (not a mismatch — a mismatch is a separate error), the task fails with 'unable to hash file <source> downloaded: <reason>'.

Source

Thrown at pkg/assets/assetcopy/copyfile.go:146

	if err != nil {
		return err
	}

	shaTarget := objectStore + shaExtension
	shaVFS, err := vfsContext.BuildVfsPath(shaTarget)
	if err != nil {
		return fmt.Errorf("error building path %q: %v", shaTarget, err)
	}

	shaHash, err := hashing.FromString(strings.TrimSpace(sha))
	if err != nil {
		return fmt.Errorf("unable to parse sha: %q, %v", sha, err)
	}

	in := bytes.NewReader(data)
	dataHash, err := shaHash.Algorithm.Hash(in)
	if err != nil {
		return fmt.Errorf("unable to hash file %q downloaded: %v", source, err)
	}

	if !shaHash.Equal(dataHash) {
		return fmt.Errorf("the sha value in %q does not match %q calculated value %q", shaTarget, source, dataHash.String())
	}

	klog.Infof("uploading %q to %q", source, objectStore)
	if err := writeFile(ctx, cluster, uploadVFS, data); err != nil {
		return err
	}

	b := []byte(shaHash.Hex())
	if err := writeFile(ctx, cluster, shaVFS, b); err != nil {
		return err
	}

	return nil
}

View on GitHub (pinned to 4c8573c808)

Solutions

Re-run the copy; this is not a content problem and is usually transient or environmental.
Check machine memory/disk health since the file was fully loaded into memory.
If reproducible, report with the kops version and the wrapped inner error.
As a workaround, ensure adequate resources for the machine running kops (large files are hashed in memory).

Example fix

// before
unable to hash file "https://.../kubelet" downloaded: unexpected EOF
// after
kops get assets --copy ...  # retry on a healthy host with sufficient RAM

Defensive patterns

Strategy: retry

Validate before calling

// Hashing over in-memory data rarely fails; verify available memory for large assets:
if runtime.NumCPU() == 0 || /* e.g. constrained env */ checkMemLimit() {
    log.Printf("insufficient resources for in-memory hashing of large assets")
}

Try / catch

err := transferFile(ctx, vfsContext, cluster, source, target, sha)
if err != nil && strings.Contains(err.Error(), "unable to hash file") {
    return retryWithBackoff(3, time.Second, func() error {
        return transferFile(ctx, vfsContext, cluster, source, target, sha)
    })
}

Prevention

Run kops on a host with enough RAM to hold the largest asset in memory
Retry — this failure is usually transient/environmental
Keep kops up to date to pick up hashing library fixes
If persistent, capture the inner error and file an issue with the kops version

When it happens

Trigger: The hash computation over the downloaded bytes returns an error — essentially only when the data reader fails mid-hash (rare, since data is an in-memory bytes.Reader), indicating an internal/library-level problem rather than a content mismatch.

Common situations: Very rare in practice; would appear alongside memory pressure or an unexpected failure in the hashing library's Hash implementation.

Related errors

AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/2c8be7e278f25353. Report an issue: GitHub.