Import scan config error "Name and base config to copy must be at least one character long"

I’ve reviewed several threads on missing import scan configurations, but am not clear how to actually get a usable scan config after syncing. Details…

I have just got GVM running and its feeds synced, but there are no configured scans and the GVMD_DATA Feed status says something like “11 days old”. I noticed there is an upload icon, and so tried to load one of the several configs on disk. FWIW, here is one file I tried:

$ cat /var/lib/gvm/data-objects/gvmd/20.08/configs/base-d21f6c81-2b88-4ac1-b7b4-a2a9f2ad4663.xml
<!-- Copyright (C) 2020 Greenbone Networks GmbH -->
<config id="d21f6c81-2b88-4ac1-b7b4-a2a9f2ad4663">
  <comment>Basic configuration template with a minimum set of NVTs required for a scan. Version 20200827.</comment>

Unfortunately, each file I tried gave what looks like a validation error “Name and base config to copy must be at least one character long”. Should this work? Is there some other way to get a scan config loaded?

EDIT: Just to confirm I redid the steps in GVM 20.08 Missing Report Formats and Scan Configs, and resync’d a couple of times to no effect.

Possibly related: if I try to create a “New Scan Config”, I get this error which, interestingly, cites the UUID of the file I showed me trying to load above:

Hello Shaheed,

regarding the error “Name and base config to copy must be at least one character long”: In the web interface, you can only import objects that have been exported via the web interface. Manually importing an object from the Greenbone Feed is not supported and causes the corresponding error.

Regarding your second post, this is the true problem. For some reason, the feed objects have not been processed by GVM yet and are thus unavailable.

Have you tried the exact steps from and Also, are the NVTs loaded correctly on your system? Nonexistant NVTs may also cause problems here sometimes.

1 Like


Thanks for your reply. Yes, not only have I confirmed with the PPA author that

setting the feed import owner for the “admin” user will be done automatically by the gvmd post-installation script

but as per the thread I mentioned, I also followed up with both sets of steps you noted.

Now, you also mentioned:

Nonexistant NVTs may also cause problems here sometimes.

I’m not really sure what NVTs are, but what is interesting is that although the NVT feed is up to date:

clicking on the link suggests I have no NVTs:

Perhaps that is a clue to the problem? I also performed another set of syncs just now (as I write, the feeds are “Update in progress…”).

Thanks, Shaheed

P.S. If you need me to check something in the database, I am able to do that using pgAdmin (in fact I did, in desperation, manually create some Scan Configs using pgAdmin though since I have no idea what I am doing, the lack of progress was very predictable ;-)).

AFAIK this happens if the scanner has loaded the VT cache but the manager daemon (gvmd) isn’t able to connect to the scanner to sync its internal one with the one of the scanner.

Make sure that:

  1. ospd-openvas is running
  2. gvmd can connect to the expected socket (see

@cfi thanks for the hint. I have double checked this as follows. First, use the ss command to verify the socket that ospd-openvas is listening on:

$ sudo ss -l -p|grep openvas
u_str  LISTEN   0  5    /var/run/ospd/ospd.sock 84414              * 0 users:(("ospd-openvas",pid=24459,fd=5))                                        
u_str  LISTEN   0  16   /tmp/pymp-281cary9/listener-ur8uga4b 84413 * 0 users:(("ospd-openvas",pid=24464,fd=10)) 

Next, check the invocation of gvmd to confirm where it is trying to connect:

# ps -eaf | grep gvmd
gvm        24471       1  0 09:32 ?        00:00:00 gvmd: Waiting for incoming connections

So there are no command arguments we can see. So that check how it was started from the systemd .service file:


ExecStart=/usr/sbin/gvmd --osp-vt-update=$OSP_VT_UPDATE $OPTIONS

The first file just contains the db credentials, and the second has:

# Unix socket for OSP NVT update (--osp-vt-update)

# Additional options
# OPTIONS="--listen= --port=9390"

So AFAICS, gvmd is expecting to connect on the same socket that ospd-openvas is listening.

Any other ideas welcome.