Docker layer blobs no longer reclaimed after 3.91.0-07 upgrade

Sonatype Nexus Repository
1

Since upgrading Nexus Repository to 3.91.0-07 (from 3.87.1-01), our Docker
hosted repo has stopped reclaiming disk space, despite the scheduled
cleanup tasks all reporting success. We’ve run Nexus for 10+ years and
used its Docker registry for the last 2–3.

We suspect it is related to an external expire script that deletes
old tags via DELETE /v2/{name}/manifests/{digest}, a monthly “Docker -
Delete unused manifests and images” task, and a daily “Admin - Compact
blob store” task.

Before upgrading Nexus our system monitoring of disc space showed a
clean monthly “sawtooth” pattern (the Docker containers are the bulk of
the disc space consumption); after the upgrade the sawtooth stopped and
the blob store has just been growing.

Environment: single Docker hosted repository, file blob store, H2 backend, no
HA/clustering.

Evidence from today:

  • du -sh on the blob store content: 157G
  • nx-blob-repo-space-report: totalBytes 168,082,071,473 / reclaimableBytes 8,792
  • DockerGCTask log: “Removed 0 unused layers” (109 tagged manifests, 36 digest
    manifests, 645 layers referenced)
  • Compact blob store log: removed 15 empty directories, otherwise nothing
  • Spot-checked an old layer on disk: .properties file present, no deleted=true;
    a REST sha256 search returns no items. So that blob exists on disk with no DB
    record and no soft-delete marker — invisible to both GC and Compact.
  • Test today: pushed a fresh tag, deleted it via our script, ran the GC and
    Compact tasks. Manifest and config metadata got cleaned up; the associated
    layer blobs did not.

A few things we’ve already ruled out or considered: there is no
*-deletions.index file at the blob store root, but my understanding
is that’s expected on H2/PostgreSQL since soft-deletes moved into the
soft_deleted_blobs table, so rebuildDeletedBlobIndex doesn’t seem to
apply. “Admin - Cleanup unused asset blobs” is present and running every
30 min. Single Docker repo, so the cross-repo layer protection shouldn’t
be in play.

We are wondering if anyone else has hit the same pattern on
3.91.0 — layer blobs accumulating on disk with no DB record and no
deleted=true — or seen something obviously wrong with the workflow
above? Happy to share full task logs, the space report JSON, and a
support zip.

1 Like
2

@Sean_Reifschneider thanks for the report, we also have one internally that is being looked at. I don’t have information yet as to when this will be fixed.

1 Like
3

Let us know if there’s anything else we can provide to assist with this.

4

First: Issue with Cleanup Policies: Preview displays artifact but they are not cleaned when the cleanup task run a year ago and now this… Since we are using a private docker repo for Docker CI staging, our disks got full in just a couple of days. This makes Nexus completely unusable. Having these kinds of problems every year just isn’t reliable enough. We’ll probably migrate away to a registry that works.

1 Like
6

We are affected here as well. Can you share if/when this issue is on the roadmap?

7

We can see there is planned fix for 3.93 addressing exactly that issue:

NEXUS-52536 - Docker GC tasks now evaluate all unreferenced blob assets across every page, ensuring unused layers beyond the first 100 are correctly identified and reclaimed during cleanup runs

We are experiencing the same issue and are in pretty much critical situation with only few GB free disk space left. Main usage is docker hosted repo. Support ticket created, we hope some fix can happen quicker than waiting to next month for 3.93

8

As a very cumbersome workaround, I downloaded everything from the registry, removed the repository and blobstore, and then recreated it. Then I uploaded everything back, so no more dangling blob assets.

9

It does seem like you are encountering NEXUS-52536 which is scheduled to be fixed in the 3.93 release in June 2026. This issue impacts the “Docker - Delete unused manifests and images” task and results in a limited number of Docker assets being deleted.

You can workaround the issue by setting the following flag in the /etc/nexus.properties file, followed by a restart:

nexus.continuation.browse.limit=100

Once restarted, rerun the “Docker - Delete unused manifests and images” and compact blob store tasks.

10

NOTE: We have tested setting the nexus.continuation.browse.limit setting and then running various jobs, and that does seem to have helped (90+GB down to 30GB for our blob store). Can confirm that works.

Thanks!