Fresh Community Containers install: missing vts schema causes all_vts report failures

Building from Source and Advanced Topics
1

Hello All,

Fresh Greenbone Community Edition container deployment on Ubuntu 24.04 using the current official compose.yaml.

gvmd version:
Greenbone Vulnerability Manager 26.37.0
Manager DB revision 281

Database meta.database_version is also 281.

VT feed imported successfully:
nvts_feed_version = 202608260610
and gvmd logged:
Updating VTs in database ... done (185649 VTs).

However, immediately afterwards:
Refreshing all_vts table...
ERROR: schema "vts" does not exist
SQL: TRUNCATE vts.all_vts;

PostgreSQL contains only the schemas:
public, scap, cert

There is no vts schema and no all_vts relation.

The normal VT tables (nvts, vt_refs, vt_severities, etc.) are present in public.

Scans complete successfully, but opening the resulting report fails with:
Failure to receive response from manager daemon

gvmd then logs:
ERROR: relation "all_vts" does not exist

Troubleshooting already attempted:

  • restarted ospd-openvas

  • VT reload completed successfully and feed reported up to date

  • ran gvmd --rebuild-gvmd-data=all

  • confirmed PostgreSQL migration container exited successfully

  • confirmed all current core images were freshly pulled from stable

Could anyone please confirm whether vts should have been created automatically in DB revision 281, and whether this is a known initialisation issue in gvmd 26.37.0 / the current Community Containers?

Thank you!

2

I had the same problem in gvmd compiled from source.

I just recompiled with ENABLE_WEB_APPLICATION_SCANNING=1 and toggled the corresponding config setting and that made the table materialise.

I think parts of gvmd assume it is compiled with ENABLE_WEB_APPLICATION_SCANNING 1 and the corresponding environment variable/config setting set to true while the parts that create the table check the feature flag.

If i read .github/workflows/container.yml correctly the containers are compiled with the same setting so check docs/feature-flags.md to see if any of the ways to toggle the running state are accessible to you.

1 Like
3

Thank you! This seems to have identified the issue.

I enabled the runtime flag in the official Community Containers deployment:

GVMD_ENABLE_WEB_APPLICATION_SCANNING=true

and confirmed it is present in the running container. The missing vts schema was still not created.

I then checked the exact image revision in use:

25f27b49f2ce760e3b612bfdf8837873057f33c2

The workflow for that revision specifies:

-DENABLE_WEB_APPLICATION_SCANNING=1

However, the source for the same revision prints:

Web application scanning is enabled

from gvmd --version when that compile-time flag is active.

My official registry.community.greenbone.net/community/gvmd:stable container does not print that line:

Greenbone Vulnerability Manager 26.37.0
Manager DB revision 281

This appears to suggest that the published container was not actually compiled with ENABLE_WEB_APPLICATION_SCANNING=1, despite the workflow specifying it.

Does that look like a container build issue?

4

I suppose so. Unfortunately i know very little about the community containers so i hope someone else can help you find threads to pull.

5

I eventually got this working.

In my case, the problem was that the published gvmd:stable container was running gvmd 26.37.0 without Web Application Scanning compiled in. The database itself was healthy, but reports failed to render because gvmd was trying to use vts.all_vts even though the vts schema had never been created.

The giveaway was that:

gvmd --version

on the stock image did not show:

Web application scanning is enabled

I rebuilt gvmd from the exact same 26.37.0 source revision used by the published image, but with the same feature flags Greenbone’s own workflow uses, including:

-DENABLE_WEB_APPLICATION_SCANNING=1

I also enabled it at runtime in the compose service:

environment:
  GVMD_ENABLE_WEB_APPLICATION_SCANNING: "true"

After recreating only the gvmd container, gvmd --version confirmed:

Web application scanning is enabled

On the next automatic SecInfo sync, gvmd detected that the Web Application VT database was missing and created the vts schema itself, including:

vts.all_vts
vts.meta
vts.web_application_vts
vts.web_application_vt_refs

At that point the previously broken reports opened normally in the web UI, and PDF export also worked.

One remaining warning was:

No ZAP VT metadata file found at /var/lib/gvm/web-application-vts/zap-alerts.json

so the Web Application/ZAP VT feed itself is still not populated, but that did not prevent normal OpenVAS reports from rendering once vts.all_vts existed.

So the underlying issue, at least in my installation, appears to be that Web Application Scanning was not compiled into the published stable gvmd image, while other parts of gvmd still assumed the vts objects existed.

I took a database dump and pinned the original image before testing this, and I only replaced the gvmd image — the PostgreSQL database and other Greenbone containers were left untouched.

Hope this helps someone with the same issue.

6

We have this problem also.

7

My gvmd --version output does not contain either ‘Web application scanning is enabled’ or ‘disabled’. Is Jimmy’s workaround still the recommended fix for Community Containers 26.37.0 / DB revision 281?

8

Closing as this seems to be a software side issue which had been reported to the dev team here:

Please follow-up there with further info, questions and similar.

1 Like