Unexpected EOF

ABe · March 18, 2026, 2:35pm

I finished pulling 1-by-1 and
These are the final edits to my docker-compose.yml to make it work.

openvas-scanner
switched from stable to 23.41.6
current stable is 23.41.7

#~line 169
  configure-openvas:
#    image: registry.community.greenbone.net/community/openvas-scanner:stable
    image: registry.community.greenbone.net/community/openvas-scanner:23.41.6
...
#~line 187
  openvas:
#    image: registry.community.greenbone.net/community/openvas-scanner:stable
    image: registry.community.greenbone.net/community/openvas-scanner:23.41.6
...
#~line 204
  openvasd:
#    image: registry.community.greenbone.net/community/openvas-scanner:stable
    image: registry.community.greenbone.net/community/openvas-scanner:23.41.6

gvm-config
switched from latest to `edge

# ~line 139
  gvm-config:
#    image: registry.community.greenbone.net/community/gvm-config:latest
    image: registry.community.greenbone.net/community/gvm-config:edge

Then it went through.

ABe · March 18, 2026, 2:35pm

I can confirm that as well. Strange enough.

curtc · March 18, 2026, 5:23pm

I can confirm as well that things are working at this time. I’m not sure exactly what the issue is but I’ve been having trouble when updating the feeds where I get the error: “short read: expected 32 bytes but got 0: unexpected EOF” over the past few weeks.

splinterino · March 24, 2026, 6:52pm

Same issue here as of March 2026. Unable to pull ospd-openvas image from registry.community.greenbone.net. Three layers always fail with “unexpected EOF”:

d1a5b178cce4 (12.04MB)
2fb2b5d962a0 (266.4kB)
f73b069df675 (4.178kB)

Tested with docker pull, docker compose pull, and skopeo copy — all fail on the same layers. Fresh Ubuntu 24.04 install, Docker 27.x. All other images pull successfully.

ChanScan · March 24, 2026, 7:32pm

stevescan · March 25, 2026, 5:23am

The issue was resolved for a few days, and I agree it has appeared again today with the opsd-openvas container same as splinterino mentioned. I was seeing issues with vulnerability-tests as well, but they resolved on the fifth attempt.

dwun · March 27, 2026, 10:26am

we are also facing problems for days now trying to pull the opsd-openvas container on our freshly installed server. tried every tag in the repo but none work, its always the EOF error

serpentes · March 27, 2026, 10:48am

o come on!

again that eof problem? how could that happen again and again?

trulyvexed · March 28, 2026, 4:01am

Was about to make a new post as I’m fairly new to this but then saw this topic and confirm I’m having the same problem.

Already had a working setup from a few weeks ago but disk had filled because of the log file defaulting to debug and the SCAP folder was larger than I’d see it get before; I thought probably best to just start fresh - started up a new VM and now the pull is failing.

Can’t do a full copy/paste as a new user is limited to 2 links but it ends with -

short read: expected 32 bytes but got 0: unexpected EOF

trulyvexed · March 28, 2026, 9:30am

FWIW - tried again this morning and got the EOF error twice but then it went through on the 3rd attempt.

alex2013 · March 28, 2026, 12:33pm

This error has happened more than once, any ideas on how to get around it?

itguy · March 30, 2026, 4:07am

Working today

itguy · March 30, 2026, 4:07am

First time installer here. gpg-data end of file. Great first impression.

pichai-fcs · March 30, 2026, 4:07am

Dear community

I got the same error while pulling ospd-opevas on fresh new docker.

Hope network fixed ASPA.

Thanks

stevescan · March 30, 2026, 2:20pm

Today I’m consistently unable to pull gvm-config

mg-ok · April 3, 2026, 2:43am

Same issue unable to pull. Its the same every test. Good luck guys! Hope it’s resolved soon!

3a0e87375a21: Pulling fs layer
5b383d88baef: Already exists
f1c73d6a2a33: Already exists
3b2e1bc4bb82: Already exists
4f4fb700ef54: Already exists
9c9cbc68a1a9: Already exists
6be8b3baf026: Already exists
c4d908c72429: Already exists
cf97ea74e3ec: Already exists
7c600badb9bd: Already exists
1ddda61d72af: Already exists
ef2b83377dea: Already exists
dbdeb09ae24d: Already exists
9bb8cd489156: Already exists
ae5034fcdd54: Already exists
short read: expected 29775500 bytes but got 0: unexpected EOF

TonyTrapper · April 3, 2026, 2:44am

I’m trying to pulling this image but i always have the issue: i probed with Alma Linux, Fedora & Red Hat using both (Podman/Docker)

Trying to pull registry.community.greenbone.net/community/openvas-scanner:stable...
Getting image source signatures
Copying blob c4d908c72429 done   | 
Copying blob dbdeb09ae24d [--------------------------------------] 0.0b / 278.4KiB | 0.0 b/s
Copying blob 3a0e87375a21 done   | 
Copying blob 6be8b3baf026 [--------------------------------------] 0.0b / 11.5MiB | 0.0 b/s
Copying blob f1c73d6a2a33 done   | 
Copying blob ef2b83377dea [--------------------------------------] 0.0b / 4.1KiB | 0.0 b/s
Copying blob 3b2e1bc4bb82 done   | 
Copying blob 9c9cbc68a1a9 done   | 
Copying blob 7c600badb9bd done   | 
Copying blob 9bb8cd489156 done   | 
Copying blob cf97ea74e3ec done   | 
Copying blob ae5034fcdd54 done   | 
Copying blob 1ddda61d72af done   | 
Copying blob 4f4fb700ef54 done   | 
Copying blob 4f4fb700ef54 done   | 
Copying blob 5b383d88baef done   | 
Error: unable to copy from source docker://registry.community.greenbone.net/community/openvas-scanner:stable: copying system image from manifest list: reading blob sha256:6be8b3baf0265e4c5c056f5f9b12f25c596305b0b3974a1df3944c5510681c6c: (heuristic tuning data: total 0 @1666.078 ms, last retry 0 @0.008 ms, last progress @ NaN ms): unexpected EOF

md-98 · April 5, 2026, 1:29pm

i also have the same problem, i tried older stable version in the compose file but got no luck, wont work…i hope it will be fixed soon.

mg-ok · April 7, 2026, 4:04am

Has anyone heard any updates on this issue?

SpencerP96 · April 7, 2026, 4:07am

Alright so hope this helps some other folks because I just spent several hours today figuring this out.

This solves the issue for me. Breakdown below.

Solution: hybrid GHCR + Greenbone registry (aarch64, verified April 2026)

Was attempting to setup community edition on an NVIDIA DGX Spark (Ubuntu 24.04, aarch64). After much much debugging, here’s what I found and what fixed it.

Problem:

Greenbone registry CDN serves broken blob streams. Manifests resolve fine, but the layer downloads die mid-stream. Docker/Podman see this as “unexpected EOF”. Retries don’t help, it’s server-side.

The fix:

On this commit: Chore: change community.greenbone to ghcr.io · greenbone/openvas-scanner@6cff36c · GitHub from March 2026, Greenbone’s own CI migrated core images to GHCR. The same images that fail from the Greenbone registry pull cleanly from GHCR.

But not everything is on GHCR. Feed images aren’t published there and redis-server only has an amd64 version. Fortunately, those images aren’t affected by the blob issue.

So the solution is a hybrid approach.

For gvmd, gsad, openvas-scanner, ospd-openvas, pg-gvm, pg-gvm-migrator, openvasd, gvm-tools, gvm-config, and nginx use ghcr.io/greenbone/*.

For vulnerability-tests, notus-data, scap-data, cert-bund-data, dfn-cert-data, data-objects, report-formats, and gpg-data use registry.community.greenbone.net.

And for redis-server use registry.community.greenbone.net as well as the GHCR version is amd64 only.

Then pin every image to a @sha256: digest so a future registry change doesn’t silently reintroduce the problem.

Bonus:

I’ve experienced this as well so figured I’d throw my solution in here in case any of you experienced it as well.

pg-gvm stale lockfile:

In my experience on several systems (Mac, Ubuntu, and just in general various x86/AMD64 systems), pg-gvm can leave a stale /var/run/postgresql/.s.PGSQL.5432.lock after an unclean shutdown. The upstream start-postgresql script doesn’t clean it. To fix:

pg-gvm:
  stop_grace_period: 60s
  command:
    - /bin/sh
    - -c
    -  |
       rm -f /var/run/postgresql/.s.PGSQL.5432.lock
       exec /usr/local/bin/start-postgresql

Tested on multiple systems and solves both issues for me. Feedback welcome.