# Full maintenance error "error rewriting contents in short packs: failed to rewrite 348 contents"

**URL:** <https://kopia.discourse.group/t/full-maintenance-error-error-rewriting-contents-in-short-packs-failed-to-rewrite-348-contents/8791>\
**Category:** General Topics\
**Created:** [January 30, 2026, 3:01pm UTC](https://kopia.discourse.group/t/full-maintenance-error-error-rewriting-contents-in-short-packs-failed-to-rewrite-348-contents/8791 "2026-01-30T15:01:22Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Statick](https://avatars.discourse-cdn.com/v4/letter/s/7feea3/32.png) [@Statick](https://kopia.discourse.group/u/Statick)\
**Post date:** [January 30, 2026, 3:01pm UTC](https://kopia.discourse.group/t/full-maintenance-error-error-rewriting-contents-in-short-packs-failed-to-rewrite-348-contents/8791/1 "2026-01-30T15:01:22Z")

</div>

hiya my repo is only a few days old and I’m already getting this problem

snapshots do not produce errors, quick maintenance does not produce errors, but full maintenance produces this every time, and the number gets larger each time

```auto
Running full maintenance...
GC found 3872 unused contents (6.9 GB)
GC found 4897 unused contents that are too recent to delete (14 GB)
GC found 177952 in-use contents (352.9 GB)
GC found 309 in-use system-contents (263.5 KB)
GC undeleted 0 contents (0 B)
Finished full maintenance.
error rewriting contents in short packs: failed to rewrite 348 contents

```

I’ve tried kopia snapshot verify at the command line and this shows no errors either

```auto
Listing blobs...
  10000 blobs...
Listed 16195 blobs.
Processed 0 objects (0 B). Read 0 files (0 B).
Processed 941 objects (95.6 GB). Read 0 files (0 B).
Processed 2856 objects (284.6 GB). Read 0 files (0 B).
Processed 5233 objects (363.7 GB). Read 0 files (0 B).
Processed 10852 objects (425.3 GB). Read 0 files (0 B).
Processed 26718 objects (440.4 GB). Read 0 files (0 B).
Processed 45395 objects (445.4 GB). Read 0 files (0 B).
Processed 64273 objects (450.6 GB). Read 0 files (0 B).
Processed 80560 objects (456.1 GB). Read 0 files (0 B).
Processed 98765 objects (480 GB). Read 0 files (0 B).
Finished processing 100862 objects (482 GB). Read 0 files (0 B).

```

and yet the “failed to rewrite” increases every time

my repo is on WebDav and I’ve aready set list parallelism to 1 as the first full maintenance was giving error 429 initially, that seems to have sorted that but I’m still getting this error

I have also tried running maintenance from my other system (both systems have snapshots in this repo) and exactly the same result there

the maintenance CLI logs contain many entries like this one

```auto
2026-01-30T12:31:09.114798Z DEBUG kopia/repo [STORAGE] GetBlob	{"blobID":"p71f37bda3bdda64bac331cb3f6578912-s9789fc19ac6cd0b513d","offset":32,"length":2598639,"outputLength":0,"error":"invalid blob offset or length","errorVerbose":"invalid blob offset or length\ngithub.com/kopia/kopia/repo/blob.init\n\t<autogenerated>:1\nruntime.doInit1\n\truntime/proc.go:7670\nruntime.doInit\n\truntime/proc.go:7637\nruntime.main\n\truntime/proc.go:256\nruntime.goexit\n\truntime/asm_amd64.s:1693","duration":"346.7033ms"}

```

I’ve checked in the repo location and the file is present, and is 2601164 bytes in size. I’ve only checked a few of the named files but they all exist and are not 0 byte files

what should I do next?

I’m tempted to just delete and start again rather than do any verification that involves downloading all the data (it’s a slow server), but also I’m concerned about using this for backups if this issue can come up so quickly and be not so easily resolved

---

<div class="post-metadata">

**Author:** ![Statick](https://avatars.discourse-cdn.com/v4/letter/s/7feea3/32.png) [@Statick](https://kopia.discourse.group/u/Statick)\
**Post date:** [January 30, 2026, 6:43pm UTC](https://kopia.discourse.group/t/full-maintenance-error-error-rewriting-contents-in-short-packs-failed-to-rewrite-348-contents/8791/2 "2026-01-30T18:43:42Z")

</div>

seems I cannot restore any data whatsoever either. every attempt to restore anything just gives

```auto
Error: error restoring: restore error: copy file: error creating file: unable to open snapshot file for d:\test\test.jpg: unable to open object: a5239dacc0e265e48b365efd30649d91: unexpected content error: error getting cached content from blob "pccbf4d6d5fd410191c85d89f269597eb-s3b58b8af04e2db9913d": failed to get blob with ID pccbf4d6d5fd410191c85d89f269597eb-s3b58b8af04e2db9913d: invalid blob offset or length.

```

it’s as if no blob files can be opened at all, while the repo itself opens fine and I can continue making snapshots fine, and I can download the blob files from the WebDav server manually without problems

---

<div class="post-metadata">

**Author:** ![Statick](https://avatars.discourse-cdn.com/v4/letter/s/7feea3/32.png) [@Statick](https://kopia.discourse.group/u/Statick)\
**Post date:** [January 30, 2026, 8:04pm UTC](https://kopia.discourse.group/t/full-maintenance-error-error-rewriting-contents-in-short-packs-failed-to-rewrite-348-contents/8791/3 "2026-01-30T20:04:16Z")

</div>

okay I just created a new repo in another location on the same WebDav server. it’s been taking a snapshot for an hour so there isn’t much in it, but I cannot restore any of the contents. just getting the same “invalid blob offset or length” error

---

<div class="post-metadata">

**Author:** ![budy](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/budy/32/38_2.png) [@budy](https://kopia.discourse.group/u/budy)\
**Post date:** [February 1, 2026, 5:55pm UTC](https://kopia.discourse.group/t/full-maintenance-error-error-rewriting-contents-in-short-packs-failed-to-rewrite-348-contents/8791/4 "2026-02-01T17:55:30Z")

</div>

A little bit of more information about your setup would sure help anyone willing to provide aid or some tip. Just going to say that WebDAV on Windows is propably the worst option to choose, as Windows generally impose a 50 MB size limit, afaik. When blobs get larger, Windows might just not retrieve them.

---

<div class="post-metadata">

**Author:** ![Statick](https://avatars.discourse-cdn.com/v4/letter/s/7feea3/32.png) [@Statick](https://kopia.discourse.group/u/Statick)\
**Post date:** [February 2, 2026, 7:19pm UTC](https://kopia.discourse.group/t/full-maintenance-error-error-rewriting-contents-in-short-packs-failed-to-rewrite-348-contents/8791/5 "2026-02-02T19:19:38Z")

</div>

it’s WebDav to a cloud storage provider (OpenDrive), so there’s no windows webdav involved, and any issues with WebDav are with them I guess. but that is what seems to be the problem - I’ve now set up rclone to the same provider and that’s working well, full maintenance is running successfully, restores are working successfully, and the snapshot upload speed has more than doubled as well. my suspicion is that their WebDav isn’t correctly reporting file sizes, so every attempt to read blobs fails, despite the fact that the files themselves can be opened no problem (repository settings, policy settings, etc all work fine, and I can download blob files manually using a webdav client no problem)

---

<div class="post-metadata">

**Author:** ![budy](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/budy/32/38_2.png) [@budy](https://kopia.discourse.group/u/budy)\
**Post date:** [February 6, 2026, 7:02am UTC](https://kopia.discourse.group/t/full-maintenance-error-error-rewriting-contents-in-short-packs-failed-to-rewrite-348-contents/8791/6 "2026-02-06T07:02:22Z")

</div>

I thought that Windows WebDAV client had that limitation, not the server. Can you check the size of the blobs which can’t be read?

---

<div class="post-metadata">

**Author:** ![Statick](https://avatars.discourse-cdn.com/v4/letter/s/7feea3/32.png) [@Statick](https://kopia.discourse.group/u/Statick)\
**Post date:** [February 12, 2026, 12:45pm UTC](https://kopia.discourse.group/t/full-maintenance-error-error-rewriting-contents-in-short-packs-failed-to-rewrite-348-contents/8791/7 "2026-02-12T12:45:04Z")

</div>

it’s literally every blob that generated the error, most of them under 10mb a few under 20mb. I think it’s the server reporting incorrect file size information, as that’s what the error suggests “invalid offset or length” on any attempt to read a blob. I’d previously used different software to upload and download very large files (GBs in size) over webdav using the same service without issues, so I don’t think there’s a size limitation coming in to play here - the files are there and can be downloaded manually, and Kopia connects to the repo fine reading the policies and snapshot data no problem (which presumably doesn’t rely on file size reporting), but failed instantly at any attempt to restore a file or run full maintenance, i.e anything that requires opening a blob. in any case, it’s working perfectly over Rclone to the same service so that’s how I’m doing it
