# Error loading indexes: unable to open pack index "xn37\_

**URL:** <https://kopia.discourse.group/t/error-loading-indexes-unable-to-open-pack-index-xn37/3890>\
**Category:** Support\
**Created:** [April 21, 2025, 7:44am UTC](https://kopia.discourse.group/t/error-loading-indexes-unable-to-open-pack-index-xn37/3890 "2025-04-21T07:44:22Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jcpandrade](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/jcpandrade/32/1407_2.png) [@jcpandrade](https://kopia.discourse.group/u/jcpandrade)\
**Post date:** [April 21, 2025, 7:44am UTC](https://kopia.discourse.group/t/error-loading-indexes-unable-to-open-pack-index-xn37/3890/1 "2025-04-21T07:44:22Z")

</div>

Hi all,

Running kopia v0.19.0 as a service on Windows 2022. All was good and running great until today. I noticed that kopia was not running. Seems the server rebooted unexpectedly and upon start kopia fails because is unable to:

ERROR failed to open repository: unable to create shared content manager: error loading indexes: unable to open pack index “xn37\_1f5e070b1d1b2f06fb60db0413e2acc8-s2403e756476a1155134-c1”: error opening index from xn37\_1f5e070b1d1b2f06fb60db0413e2acc8-s2403e756476a1155134-c1: invalid header: invalid header  
ERROR open repository: unable to open repository: unable to create shared content manager: error loading indexes: unable to open pack index “xn37\_1f5e070b1d1b2f06fb60db0413e2acc8-s2403e756476a1155134-c1”: error opening index from xn37\_1f5e070b1d1b2f06fb60db0413e2acc8-s2403e756476a1155134-c1: invalid header: invalid header

The repository is stored in a S3 compatible system and while looking into it I don’t see any object with a name starting with “x”.  
I still have the cache. Is there some way to restore the repository?

---

<div class="post-metadata">

**Author:** ![jcpandrade](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/jcpandrade/32/1407_2.png) [@jcpandrade](https://kopia.discourse.group/u/jcpandrade)\
**Post date:** [April 21, 2025, 8:47am UTC](https://kopia.discourse.group/t/error-loading-indexes-unable-to-open-pack-index-xn37/3890/2 "2025-04-21T08:47:09Z")

</div>

Ok, the **xn** files seem to be there, I had to use another tool to list the S3 content. Also, that particular file mentioned in the logs is there.  
Is ti possible to correct that index somehow? Or skip it and access the remainder of the repository?

 ![image](https://global.discourse-cdn.com/free1/uploads/kopia/original/2X/7/78995146a0c4b8bdc5051685af5178d65a641557.png)

---

<div class="post-metadata">

**Author:** ![dimejo](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/dimejo/32/287_2.png) [@dimejo](https://kopia.discourse.group/u/dimejo)\
**Post date:** [April 21, 2025, 9:53am UTC](https://kopia.discourse.group/t/error-loading-indexes-unable-to-open-pack-index-xn37/3890/3 "2025-04-21T09:53:03Z")

</div>

> [@jcpandrade](#):
>
> Hi all,

Hey and welcome 👋

> [@jcpandrade](#):
>
> Is there some way to restore the repository?

- If possible, make a copy of your repository to test your changes
- If object lock is enabled for your bucket, search for an earlier uncorrupted version of the index file
- If you can’t recover the index file, rename it and try connecting again
- Run `kopia snap verify` to check your repository. This should print an error message
- Run `kopia snap fix invalid-files` to check which files need to be corrected. Add `--commit` to this command to rewrite files and correct the errors.

---

<div class="post-metadata">

**Author:** ![jcpandrade](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/jcpandrade/32/1407_2.png) [@jcpandrade](https://kopia.discourse.group/u/jcpandrade)\
**Post date:** [April 21, 2025, 12:01pm UTC](https://kopia.discourse.group/t/error-loading-indexes-unable-to-open-pack-index-xn37/3890/4 "2025-04-21T12:01:11Z")

</div>

Thank you for your quick answer!

- I am making a copy of the repository (still ongoing, over 5TBs).
- Unfortunately, this S3 compatible and, as fr as I know, does not even support object lock. So…
- I don’t think I will be able to recover the index file. So, once the copy is done, I will try to follow with rename and try to connect.
- I assume that I can run that `kopia snap verify` from a different computer, right? I am asking because, a few hours before this issue came up, I also experienced an issue with the source data and, before making any repairs to it, I am performing a backup to a new repository (I preserved all the original kopia config and cache in a different directory). This backup will take a huge amount of time and I would really like to be able to move on to perform the so much needed filesystem check (that will also take a lot of time)…

Again, thank you for your very fast help!

---

<div class="post-metadata">

**Author:** ![jcpandrade](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/jcpandrade/32/1407_2.png) [@jcpandrade](https://kopia.discourse.group/u/jcpandrade)\
**Post date:** [April 21, 2025, 1:33pm UTC](https://kopia.discourse.group/t/error-loading-indexes-unable-to-open-pack-index-xn37/3890/5 "2025-04-21T13:33:59Z")

</div>

Update on the current status:

After copying the repository to another bucket, I used a different computer to access the original.  
The `kopia snap verify` displayed no erros and I was able to list my snapshots. So, I moved back to the original computer and renamed the “cache” directory, where I believe the issue is.  
I performed a new verify, this time using `kopia snap verify --verify-files-percent=1 --file-parallelism=5 --parallel=5` and I got no errors.

I am now going back to use the original repository.

Thank you, @dimejo for your precious help on this!!!

---

<div class="post-metadata">

**Author:** ![dimejo](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/dimejo/32/287_2.png) [@dimejo](https://kopia.discourse.group/u/dimejo)\
**Post date:** [April 21, 2025, 8:11pm UTC](https://kopia.discourse.group/t/error-loading-indexes-unable-to-open-pack-index-xn37/3890/6 "2025-04-21T20:11:16Z")

</div>

> [@jcpandrade](#):
>
> So, I moved back to the original computer and renamed the “cache” directory, where I believe the issue is.  
> I performed a new verify, this time using `kopia snap verify --verify-files-percent=1 --file-parallelism=5 --parallel=5` and I got no errors.

Wouldn’t habe thought the cache could cause this issue. Will have to add that to future troubleshooting.

> [@jcpandrade](#):
>
> Thank you, @dimejo for your precious help on this!!!

Thank you for reporting back on the solution!
