Can't view scan reports (even past ones) - get "An error has occurred on this page"

[markdesilva]

Describe the bug
Click on 'Scans -> Reports" or click on any report from the 'Tasks' view and get the "An error has occurred on this page"

To Reproduce
Steps to reproduce the behavior:

1. Click on 'Scans->Reports' or click on any report from the 'Tasks' view
2. Get the "An error has occurred on this page"

Expected behavior
See list of reports

Screenshots
-NA-

Additional context

/usr/local/var/log/gvm/gvmd.log shows this:

md manage:WARNING:2020-09-16 17h11.48 +08:2850: run_report_format_script: No generate script found at /usr/local/var/lib/gvm/gvmd/report_formats/generate

/usr/local/var/lib/gvm/gvmd only has the subdirectory gnupg but doesn't have reports_format subdirectory.

I found 'report_formats' subdirectory in :

/usr/local/var/lib/gvm/data-objects/gvmd/21.04/report_formats
/usr/local/var/lib/gvm/data-objects/gvmd/20.08/report_formats

but neither of those directories has the generate script.

Error details that are available on the reports page are:

TypeError: s is undefined
in mG
in tbody
in t
in styled.tbody
in table
in Unknown
in t
in Styled(StripedTable)
in div
in Unknown
in t
in Styled(Layout)
in n
in Unknown
in div
in Unknown
in t
in Layout
in section
in tr
in n
in div
in Unknown
in t
in Layout
in n
in w
in Unknown
in n
in n
in w
in withRouter(Connect(n))
in n
in Unknown
in l
in w
in Unknown
in a
in n
in Unknown
in Tg
in n
in Unknown
in w
in Unknown
in t
in t
in n
in main
in t
in Main
in Unknown
in t
in withLayout(Main)
in div
in Unknown
in t
in Styled(Layout)
in n
in withRouter(n)
in Unknown
in n
in w
in withRouter(Connect(n))
in Unknown
in n
in w
in withRouter(Connect(n))
in Unknown
in t
in t
in Unknown
in Unknown
in n
in w
in l
in n
in n

mG@https:///static/js/main.bc743b66.chunk.js:1:1448860
Gi@https:///static/js/2.f7d69170.chunk.js:2:684338
bc@https:///static/js/2.f7d69170.chunk.js:2:730750
us@https:///static/js/2.f7d69170.chunk.js:2:723279
cs@https:///static/js/2.f7d69170.chunk.js:2:723202
Zc@https:///static/js/2.f7d69170.chunk.js:2:720211
Vo/<@https:///static/js/2.f7d69170.chunk.js:2:671596
t.unstable_runWithPriority@https:///static/js/2.f7d69170.chunk.js:2:747183
Yo@https:///static/js/2.f7d69170.chunk.js:2:671305
Vo@https:///static/js/2.f7d69170.chunk.js:2:671543
Uo@https:///static/js/2.f7d69170.chunk.js:2:671476
es@https:///static/js/2.f7d69170.chunk.js:2:720502
notify@https:///static/js/2.f7d69170.chunk.js:2:29000
u</t.notifyNestedSubs@https:///static/js/2.f7d69170.chunk.js:2:29635
u</t.handleChangeWrapper@https:///static/js/2.f7d69170.chunk.js:2:29703
b@https:///static/js/2.f7d69170.chunk.js:2:115881
r/</</<@https:///static/js/2.f7d69170.chunk.js:2:517001
dispatch@https:///static/js/2.f7d69170.chunk.js:2:119649
u/</</</<@https:///static/js/main.bc743b66.chunk.js:1:54

[markdesilva]

By the way this is for the latest pull (v20.08).

[pixelsquared]

I think this is because your image was upgraded and the database has the info for the old reports locations but I am not sure I will try to reproduce the issue.

[markdesilva]

On a clean system, the image runs properly so you're probably right about the database holding the older info for v11 causing the issues.

Any idea how to fix it? Seems like v20.08 may change a few things from v11 in the db, with the ospd.sock and the reports being just 2 things discovered so far.

Is there an admin user and password for us to access the pgdb? I didn't see that on the env variables list or anywhere else in the documentation, unless I missed it.

Thanks for your help solving this and all the effort - appreciate the work you do maintaining this.

[pixelsquared]

Hi sorry for not responding sooner. There is a env variable for the database user password DB_PASSWORD and the username is gvm. Then you just need to connect to the PostgreSQL database on port 5432.

[pixelsquared]

I believe I have found a solution for this issue. I will try to get a fix out tomorrow.

[pixelsquared]

Nevermind about tomorrow I might have a fix in the master image. If you could try the master image and see if it fixes this issue that would be helpful.

[markdesilva]

Thanks. Sorry for the late reply, stuck in meetings all day.

Will give it a try and get back to you.

Nevermind about tomorrow I might have a fix in the master image. If you could try the master image and see if it fixes this issue that would be helpful.

[markdesilva]

Nevermind about tomorrow I might have a fix in the master image. If you could try the master image and see if it fixes this issue that would be helpful.

Just tried out the master image, no go. The "An error occurred on this page. Please try again." still happens.

Same error details, "TypeError: s is undefined".

Thanks.

[pixelsquared]

Well then back to the drawing board

[kendyblack]

Could not connect to Scanner at /var/run/ospd/ospd.sock
the issue fixed ?

[markdesilva]

Could not connect to Scanner at /var/run/ospd/ospd.sock
the issue fixed ?

There is a soft link from /tmp to /var/run/ospd so that fixes it but the reports still won't show.

[kendyblack]

i don't keep previos database so i remove container end volume . after remove i install new container gvm. reports is show . through the second day , the reports still won't show and scan task stop after some seconds

[markdesilva]

i don't keep previos database so i remove container end volume . after remove i install new container gvm. reports is show . through the second day , the reports still won't show and scan task stop after some seconds

Which is weird. If you delete the container and the physical volume (/var/lib/docker/volumes/gvm-data/_data), then you shouldn't need to bother about the location of the /var/run/ospd/ospd.sock. The soft link is only necessary if you are upgrading because the v11 sock location is in /tmp/ and this is stored in the database (which will be kept in /var/lib/docker/volumes/gvm-data/_data). For the same reason, upgrading also causes the reports to fail to show.

If you run a clean install (delete the previous gvm container, delete /var/lib/docker/volumes/gvm-data), everything (scans, reports, etc) works out of the box, no changes necessary.

[DocSnyd3r]

Hi,
because of this I tried to go back to 11.0.1-v1 but the db will no longer connect...

(gvmd:74): md manage-WARNING **: 13:57:14.605: sql_open: PQerrorMessage (conn): FATAL: role "gvm" does not exist

Do I have to apply a backup or is there an easy fix. In the future how will we know if an update breaks everything?

[markdesilva]

Probably apply the back up. 20.08 does some update to the db, even if it doesn't replace the socket or reports locations and settings.

I got things running on a VM so I made a snapshot before updating. Once I determined 20.08 wasn't working for me, I reverted to the snapshot and got back to v11 without fuss.

[miyoyo]

This issue seems to be related to a Podman-specific bug.
Specifically: containers/podman#4318
When mounting your volumes, use this specific syntax instead: --volume gvm-data:/data:exec, this allows the report-building scripts to be executed from the volume.

[austinsonger]

https://github.com/Secure-Compliance-Solutions-LLC/gitbook/blob/master/openvas-greenbone-deployment-full-guide/faq.md

[markdesilva]

This fixes podman maybe, but not docker?

From the link you gave, its mentioned docker's default is to mount volumes with exec already. (containers/podman#4318 (comment))

Also the 'exec' doesn't work with docker, I get this:

docker: Error response from daemon: invalid mode: exec.

Which seems to coincide with what was said in the link you gave, as docker has no such 'exec' flag.
(containers/podman#4318 (comment))

This issue seems to be related to a Podman-specific bug.
Specifically: containers/podman#4318
When mounting your volumes, use this specific syntax instead: --volume gvm-data:/data:exec, this allows the report-building scripts to be executed from the volume.

[github-actions]

Stale issue message