OSP service has different VT status

Hello, I’m struggling with an issue of launching Community Containers with default configuration. After initial launch of different components, gvmd starts logging this:

gvmd-1                 | md manage:   INFO:2024-06-20 15h45.23 UTC:126: OSP service has different VT status (version 202406170933) from database (version (null), 0 VTs). Starting update ...
gvmd-1                 | md manage:   INFO:2024-06-20 15h47.05 UTC:149: OSP service has different VT status (version 202406170933) from database (version (null), 0 VTs). Starting update ...
gvmd-1                 | md manage:   INFO:2024-06-20 15h48.32 UTC:163: OSP service has different VT status (version 202406170933) from database (version (null), 0 VTs). Starting update ...

There are no error messages, just these same messages appear every minute.

Moreover, if I try to create scan config in web-UI, error “Failed to find config ‘<some_uuid>’”, and log message

gvmd-1                 | event config:MESSAGE:2024-06-20 15h52.10 UTC:236: Config could not be created by admin

appear

I guess it is related to lack of VT records in database, because VTs update can’t be finished (or event started). After reading some source code, my suggestion is that this function call ends unsuccessfully, but no errors are shown.

As I’ve said, I’m trying to start the system with default docker-compose file, so no additional users are created.

According to the Greenbone docker containers workflow, the first message is normal for gvmd VTs loading log message during feed update. Next you should eventually see

When gvmd has finished loading all VTs, the following message appears:

Updating VTs in database ... done (X VTs).

So, check your logs for that message. It may just take some time for the VTs to load. Otherwise, maybe check your available disk space. :thinking:

Waiting for some time was my initial idea. I’ve started the containers and waited for the whole day, but the same message kept appearing.

Speaking of disk space, I have more than 100gb free, so I think it’s not the case

Can the fact that I’m running the system on MacOS be the possible reason behind that problem?

I have the same problem with Kali linux, so it seems the OS is not the problem.

I’ve managed to run OpenVAS successfully when I ran it on ubuntu VM, not on MacOS

So on MacOS I use colima for running docker. Initially I thought it was the rootcause of my issue, cause my collegue, who uses DockerDesktop on same Mac model, ran OpenVAS without any issues

But if you say Kali Linux fails to run it too, then it is indeed something else