macOS client cannot open repository after index compaction, but another Mac opens it fine (filesystem repository on QNAP SMB)

General Topics
1

Hi,

I’m evaluating Kopia before committing several more terabytes of backups to it. I’ve spent several hours narrowing this down and I’m hoping someone can tell me whether this is expected behavior, a client issue, or a bug.

Environment

Repository

  • Filesystem repository

  • Stored on a QNAP NAS

  • Accessed via SMB

  • Repository path:

    /Volumes/Backups/Kopia/Repository

Clients

  • Mac Pro (Intel)
  • MacBook Pro 15" (2015 Intel)

Both are running Kopia 0.23.1.

What happened

Everything was working normally.

I created backups from both Macs into the same repository.

The MacBook then stopped showing the newest snapshots created by the Mac Pro, although it still showed older snapshots.

After restarting KopiaUI on the MacBook, it could no longer connect to the repository.

The Mac Pro has continued working normally the entire time.

Error

Every connection attempt from the MacBook fails with:

failed to open repository:
unable to create shared content manager:
error loading indexes:
error downloading indexes:
error loading index blob
xs1_74c07bd06d913590cb6203dc26ad40aa-sa31980f89a0eefa5-c1

decrypt blob

cipher: message authentication failed

Things I have verified

  • Same repository path
  • Same SMB share
  • Same repository ID
  • Same repository configuration
  • Same repository password
  • Same Kopia version
  • Deleted local cache
  • Deleted local repository.config
  • Created a completely fresh repository connection from the CLI
  • Entered repository password manually

The failure is identical every time.

Mac Pro behavior

The Mac Pro can:

  • reconnect successfully
  • restart KopiaUI successfully
  • list snapshots
  • run:
kopia repository status

without issue.

It can also list the offending blob:

kopia blob list --prefix xs1_74c07bd06d913590cb6203dc26ad40aa

Output:

xs1_74c07bd06d913590cb6203dc26ad40aa-sa31980f89a0eefa5-c1
length: 49,312,197 bytes
timestamp: 2026-07-29 21:47:16 EDT

It can also read that blob successfully:

kopia blob show xs1_74c07bd06d913590cb6203dc26ad40aa-sa31980f89a0eefa5-c1 > /tmp/xs1.bin

which completes successfully.

Repository maintenance

The maintenance log shows that shortly before this started:

  • epoch advanced
  • approximately 310 index blobs were compacted
  • the above xs1 blob was created immediately afterward

The MacBook originally stopped seeing newer snapshots around this time.

After restarting Kopia, it could no longer connect at all.

Things that seem important

The repository itself appears healthy because another client can:

  • disconnect
  • reconnect
  • read snapshots
  • enumerate blobs
  • read the specific blob that the failing client complains about.

The problem appears to be isolated to one macOS client.

Questions

  1. Does this point toward repository corruption, or does it suggest a client-specific issue?
  2. Is there a diagnostic command that can verify why this particular blob fails authentication on one client but not another?
  3. Has anyone seen this after epoch/index compaction?
  4. Is there anything else I can collect before attempting more invasive recovery steps?

I’d appreciate any guidance. Since I’m evaluating Kopia for long-term backups, I’d like to understand the root cause before committing additional data to the repository.