TypeError: can't access property "scan_run_status", s is undefined

[Virsacer]

Expected behavior

Display the Reports-page

Actual behavior

As soon as there are Reports, the Reports-page displays this error:

An error occurred on this page.
Please try again.
Hide Error Details

TypeError: can't access property "scan_run_status", 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://127.0.0.1:8443/static/js/main.85dcf160.chunk.js:1:1448864
Gi@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:684354
bc@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:730766
us@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:723295
cs@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:723218
Zc@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:720227
Vo/<@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:671612
t.unstable_runWithPriority@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:747199
Yo@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:671321
Vo@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:671559
Uo@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:671492
es@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:720518
notify@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:29016
u</t.notifyNestedSubs@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:29651
u</t.handleChangeWrapper@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:29719
b@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:115897
r/</</<@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:517017
dispatch@https://127.0.0.1:8443/static/js/2.2381725e.chunk.js:2:119665
u/</</</<@https://127.0.0.1:8443/static/js/main.85dcf160.chunk.js:1:54064

Steps to reproduce

build from official release https://community.greenbone.net/t/gvm-20-08-stable-initial-release-2020-08-12/6312
new DB
new user
set import-owner
rebuild-scap
rebuild nvt
create first task
run first task
go to Reports-page

GVM versions

gsa: (gsad --version)
Greenbone Security Assistant 20.08.0~git

gvm: (gvmd --version)
Greenbone Vulnerability Manager 20.08.0
Manager DB revision 233

openvas-scanner: (openvassd --version)
bash: openvassd: command not found

gvm-libs:
20.8

Environment

Ubuntu 20.04

Installation method / source: (packages, source installation)
https://community.greenbone.net/t/gvm-20-08-stable-initial-release-2020-08-12/6312

Logfiles

event task:MESSAGE:2020-08-16 16h48.31 CEST:1594: Status of task  (fea3b731-5f55-4465-a8dc-32037509c1e8) has changed to New
event task:MESSAGE:2020-08-16 16h48.31 CEST:1594: Task TEST (fea3b731-5f55-4465-a8dc-32037509c1e8) has been created by admin
event task:MESSAGE:2020-08-16 16h48.51 CEST:1701: Status of task TEST (fea3b731-5f55-4465-a8dc-32037509c1e8) has changed to Requested
event task:MESSAGE:2020-08-16 16h48.51 CEST:1701: Task TEST (fea3b731-5f55-4465-a8dc-32037509c1e8) has been requested to start by admin
event task:MESSAGE:2020-08-16 16h49.02 CEST:1712: Status of task TEST (fea3b731-5f55-4465-a8dc-32037509c1e8) has changed to Queued

[swaterkamp]

Hi @Virsacer,
thanks for reporting this issue. I have been trying to reproduce this with a lot of parameters now, but for me 20.08 is working just fine. I think there is something more specific between the steps "run first task" and "go to Reports-page" needed to break GSA. Do you have any additional information on task or report specifics (the status of the task such as requested, queued, running and so on seemingly does not have any impact, for example).
Best,
Steffen

[Virsacer]

After I saw the error the task was still "queued", but after it was "finished" the error did still occur.
So before clicking run and after deleting the task and the recycle bin the reports-page showed no error.

Thank you for trying to reproduce it.
I guess I have to do some testing to find out more details...

[Virsacer]

I rebuilt everything from source, repeated the other steps and I get the same error...

Tried to pull the report with gvm-cli and this looks ok:

<get_reports_response status="200" status_text="OK"><report id="202084e1-0aea-41af-b315-cac1563073fe" format_id="a994b278-1f62-11e1-96ac-406186ea4fc5" extension="xml" content_type="text/xml"><owner><name>admin</name></owner><name>2020-08-18T21:18:27Z</name><comment></comment><creation_time>2020-08-18T21:18:27Z</creation_time><modification_time>2020-08-18T21:26:44Z</modification_time><writable>0</writable><in_use>0</in_use><task id="43353b37-f8c2-4d6e-91ce-ab9af2ce6f15"><name>TEST</name></task><report_format id="a994b278-1f62-11e1-96ac-406186ea4fc5"><name>XML</name></report_format></report><filters id=""><term>apply_overrides=0 min_qod=70 first=1 rows=10 sort=name</term><keywords><keyword><column>apply_overrides</column><relation>=</relation><value>0</value></keyword><keyword><column>min_qod</column><relation>=</relation><value>70</value></keyword><keyword><column>first</column><relation>=</relation><value>1</value></keyword><keyword><column>rows</column><relation>=</relation><value>10</value></keyword><keyword><column>sort</column><relation>=</relation><value>name</value></keyword></keywords></filters><sort><field>name<order>ascending</order></field></sort><reports start="1" max="1000"/><report_count>1<filtered>1</filtered><page>1</page></report_count></get_reports_response>

A reportformat with id a994b278-1f62-11e1-96ac-406186ea4fc5 is also listed on the reportformats-page...

[Virsacer]

Continuing from #2418

The means Postgres can't find the gvmd server-side library.

Best solution is probably to add /gvm/lib/ to /etc/ld.so.conf and then run ldconfig (as root). See number 6 here.

This serve-side library is a pain but there's not an easy way for us to get rid of it.

@mattmundell Ok, I had used "ldconfig /gvm/lib" but apparently this was not enough...
Now I get a report with details="1":

<get_reports_response status="200" status_text="OK">
  <report id="47d2000d-c038-4e53-a9c0-1bf7bba76868" format_id="a994b278-1f62-11e1-96ac-406186ea4fc5" extension="xml" content_type="text/xml">
    <owner>
      <name>admin</name>
    </owner>
    <name>2020-09-02T19:26:04Z</name>
    <comment/>
    <creation_time>2020-09-02T19:26:04Z</creation_time>
    <modification_time>2020-09-02T19:34:23Z</modification_time>
    <writable>0</writable>
    <in_use>0</in_use>
    <task id="1fd0c077-0bcf-4799-8975-71b9feaaab63">
      <name>TEST</name>
    </task>
    <report_format id="a994b278-1f62-11e1-96ac-406186ea4fc5">
      <name>XML</name>
    </report_format>
  </report>
  <filters id="">
    <term>apply_overrides=0 min_qod=70 first=1 rows=10 sort=name</term>
    <keywords>
      <keyword>
        <column>apply_overrides</column>
        <relation>=</relation>
        <value>0</value>
      </keyword>
      <keyword>
        <column>min_qod</column>
        <relation>=</relation>
        <value>70</value>
      </keyword>
      <keyword>
        <column>first</column>
        <relation>=</relation>
        <value>1</value>
      </keyword>
      <keyword>
        <column>rows</column>
        <relation>=</relation>
        <value>10</value>
      </keyword>
      <keyword>
        <column>sort</column>
        <relation>=</relation>
        <value>name</value>
      </keyword>
    </keywords>
  </filters>
  <sort>
    <field>name<order>ascending</order></field>
  </sort>
  <reports start="1" max="1000"/>
  <report_count>1<filtered>1</filtered><page>1</page></report_count>
</get_reports_response>

But there should be a "Greenbone Security Assistant (GSA) Default Credentials" in the report...
And the reports-page still shows "TypeError: can't access property "scan_run_status", s is undefined"...

==> /gvm/var/log/gvm/gvmd.log <==
event task:MESSAGE:2020-09-02 21h34.23 CEST:937: Status of task TEST (1fd0c077-0bcf-4799-8975-71b9feaaab63) has changed to Done

==> /gvm/var/log/gvm/gsad.log <==
gsad main:WARNING:2020-09-02 21h46.44 CEST:201: MHD: Error: received handshake message out of context

==> /gvm/var/log/gvm/gvmd.log <==
md   main:WARNING:2020-09-02 19h48.01 utc:10829: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.
md   main:WARNING:2020-09-02 21h48.01 CEST:10832: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.
md   main:WARNING:2020-09-02 19h48.18 utc:10840: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.
md   main:WARNING:2020-09-02 21h48.18 CEST:10843: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.
md   main:WARNING:2020-09-02 19h48.38 utc:10855: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.
md   main:WARNING:2020-09-02 21h48.38 CEST:10861: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.

Do you have any idea what could be wrong?

[mattmundell]

Do you have any idea what could be wrong?

Not sure. Might help to post the full GMP command you used. Perhaps your scan has no results. Perhaps try in GSA and see what GMP it uses.

[Virsacer]

I used this command:

pip3 install gvm-tools
sudo -u daemon /usr/local/bin/gvm-cli --gmp-username admin --gmp-password admin tls --xml '<get_reports report_id="47d2000d-c038-4e53-a9c0-1bf7bba76868" details="1"/>' --pretty

And a result exists:

Perhaps try in GSA and see what GMP it uses.

Sorry I dont understand what you mean...
This is the reports-page:

[palpaga]

Same problem

[bjoernricks]

Picking up this issue. The error in GSA is caused by gvmd not sending the report details which GSA is expecting here.

You need to look at the gvmd.log file for errors. It is very likely that your setup is broken. In the past either the report formats couldn't be loaded because the feed import owner has not been set or the postgres db wasn't setup correctly because the pg_crypto extension was missing or the build binary extension couldn't be loaded.

[Virsacer]

I even switched from ubuntu to debian, but it is still not working...
And there is nothing suspicious in the logfile: gvmd.log

gvmd=> SELECT * FROM pg_extension;
                            List of installed extensions
   Name    | Version |   Schema   |                   Description
-----------+---------+------------+-------------------------------------------------
 pgcrypto  | 1.3     | public     | cryptographic functions
 plpgsql   | 1.0     | pg_catalog | PL/pgSQL procedural language
 uuid-ossp | 1.1     | public     | generate universally unique identifiers (UUIDs)
(3 rows)

[csydler]

Same issue on my site after upgrade to 20.08.00.
checked everything extensions OK. rebuild from scratch also wiped DB and so on.
Everything OK except that Reports issue.

[Yan-Son]

Same error.
I've combined everything in one docker container, and issue repeats.
https://github.com/Yan-Son/AcroOpenVAS (openvas.1/Dockerfile)

[Kanshiroron]

This is reproduced on our side as well.
@swaterkamp do you have any status on this bug? Were you able to reproduce the bug? Do you need us to provide you more information?
Thanks for your help

[swaterkamp]

Current status is, that I still can't reproduce it in GSA, but obviously it's a real bug somewhere. The ticket concerning this issue is active!

[Funkensalmler]

Same issue here after the update to version 20.08.
Personal workaround: Viewing the results under "Scans -> Results" works fine. Thus by filtering this view for specific IP ranges one can achieve a view similar to a report.

[huynguyenvti]

Same issue. GSA version: 20.08.0~git

--------------------------- Error detail --------------------
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
TypeError: Cannot read property 'scan_run_status' of undefined
at mG (https://192.168.2.178:9392/static/js/main.396f2931.chunk.js:1:1448866)
at Gi (https://192.168.2.178:9392/static/js/2.cbce0950.chunk.js:2:684354)
at bc (https://192.168.2.178:9392/static/js/2.cbce0950.chunk.js:2:730766)
at us (https://192.168.2.178:9392/static/js/2.cbce0950.chunk.js:2:723293)
at cs (https://192.168.2.178:9392/static/js/2.cbce0950.chunk.js:2:723218)
at Zc (https://192.168.2.178:9392/static/js/2.cbce0950.chunk.js:2:720227)
at https://192.168.2.178:9392/static/js/2.cbce0950.chunk.js:2:671612
at t.unstable_runWithPriority (https://192.168.2.178:9392/static/js/2.cbce0950.chunk.js:2:747199)
at Yo (https://192.168.2.178:9392/static/js/2.cbce0950.chunk.js:2:671321)
at Vo (https://192.168.2.178:9392/static/js/2.cbce0950.chunk.js:2:671557)

[jfortier-haptiq]

Okay, glad I'm not the only one getting this issue. Even tried gsa-21.04 branch with no luck.

[Virsacer]

I'm wondering, what @swaterkamp is doing differently so that he does not get the error...
I tried Ubuntu and Debian with and without Docker but still every time :/

[bjoernricks]

We can't reproduce the issue at all. Neither any developer nor any of our customers has this issue. Therefore it is very very likely an issue with the setup.

Would be nice to get a detailed step by step guide on how to reproduce the issue reliably when installing our software from sources (at best from the 20.08 release branches.

[kees-closed]

We can't reproduce the issue at all. Neither any developer nor any of our customers has this issue. Therefore it is very very likely an issue with the setup.

Would be nice to get a detailed step by step guide on how to reproduce the issue reliably when installing our software from sources (at best from the 20.08 release branches.

I have a good example then. This container setup is done according to the official documentation. You may build the container, or pull it from Docker Hub. You can reproduce the error there and perhaps troubleshoot if you have the time and interest.

[Virsacer]

Here are my steps to reproduce:
Install Debian from Netboot.iso with SSH and standard system utilities

apt-get install --no-install-recommends bison clang-format cmake doxygen g++ gcc-mingw-w64 git gnutls-bin graphviz heimdal-dev libglib2.0-dev libgnutls28-dev libgpgme-dev libhiredis-dev libical-dev libksba-dev libldap2-dev libmicrohttpd-dev libpcap-dev libpopt-dev libradcli-dev libsnmp-dev libssh-gcrypt-dev libxml2-dev make nmap nodejs pkg-config postgresql-11 postgresql-server-dev-11 python3-dev python3-setuptools redis-server rsync sudo unzip xml-twig-tools xmltoman xsltproc yarnpkg

mkdir /BUILD && cd /BUILD

wget https://github.com/greenbone/openvas-smb/archive/v1.0.5.tar.gz && tar -xzf v1.0.5.tar.gz && rm v1.0.5.tar.gz
wget https://github.com/greenbone/gvm-libs/archive/v20.8.0.tar.gz && tar -xzf v20.8.0.tar.gz && rm v20.8.0.tar.gz
wget https://github.com/greenbone/gvmd/archive/v20.8.0.tar.gz && tar -xzf v20.8.0.tar.gz && rm v20.8.0.tar.gz
wget https://github.com/greenbone/openvas/archive/v20.8.0.tar.gz && tar -xzf v20.8.0.tar.gz && rm v20.8.0.tar.gz
wget https://github.com/greenbone/ospd/archive/v20.8.1.tar.gz && tar -xzf v20.8.1.tar.gz && rm v20.8.1.tar.gz
wget https://github.com/greenbone/ospd-openvas/archive/v20.8.0.tar.gz && tar -xzf v20.8.0.tar.gz && rm v20.8.0.tar.gz
wget https://github.com/greenbone/gsa/archive/v20.8.0.tar.gz && tar -xzf v20.8.0.tar.gz && rm v20.8.0.tar.gz

cd /BUILD/openvas-smb-1.0.5 && mkdir build && cd build && cmake .. && make && make install
cd /BUILD/gvm-libs-20.8.0 && mkdir build && cd build && cmake .. && make && make install
cd /BUILD/gvmd-20.8.0 && mkdir build && cd build && cmake .. && make && make install
cd /BUILD/openvas-20.8.0 && mkdir build && cd build && cmake .. && make && make install
cd /BUILD/ospd-20.8.1 && python3 setup.py install
cd /BUILD/ospd-openvas-20.8.0 && python3 setup.py install
cd /BUILD/gsa-20.8.0 && mkdir build && cd build && cmake .. && make && make install

ldconfig

service redis-server stop
echo -e "daemonize yes\nunixsocket /run/redis/redis.sock\nunixsocketperm 770\ntimeout 0\ndatabases 1025\nmaxclients 10000\nlogfile /var/log/redis/redis.log" > /etc/redis/redis.conf
mkdir /var/run/redis
redis-server /etc/redis/redis.conf

sudo -u postgres createuser root
sudo -u postgres createdb -O root gvmd
sudo -u postgres psql -d gvmd -c "CREATE EXTENSION \"uuid-ossp\";"
sudo -u postgres psql -d gvmd -c "CREATE EXTENSION \"pgcrypto\";"
sudo -u postgres psql -d gvmd -c "CREATE ROLE dba WITH SUPERUSER NOINHERIT;"
sudo -u postgres psql -d gvmd -c "GRANT dba TO root;"

gvm-manage-certs -a
greenbone-feed-sync --type GVMD_DATA
greenbone-feed-sync --type SCAP
greenbone-feed-sync --type CERT

chown daemon /usr/local/var/run/feed-update.lock
chown -R daemon /usr/local/var/lib/openvas/plugins
sudo -u daemon greenbone-nvt-sync

gvmd --create-user admin
gvmd --user=admin --new-password=admin
gvmd --get-users --verbose
gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value a940bf91-1e41-4942-954c-eea5d9854a05
gvmd --rebuild-scap

ospd-openvas --unix-socket=/usr/local/var/run/ospd/ospd-openvas.sock
gvmd --osp-vt-update=/usr/local/var/run/ospd/ospd-openvas.sock --listen=0.0.0.0
gsad --mlisten=127.0.0.1

gvmd --get-scanners
gvmd --modify-scanner=08b69003-5fc2-4037-a479-93b440211c73 --scanner-host=/usr/local/var/run/ospd/ospd-openvas.sock

Now login to GSA and wait until all SecInfo is present.
Create new alterable Task "TEST" with new Target "127.0.0.1" named "LOCAL" using new Portlist "T:443" named "SSL"
Go to Reports -> Everything ok
Go to Task and click "Start"
Go to Reports -> Error (even before Task is "Queued")

[cfi-gb]

I can see that both, the docker image https://github.com/AquaL1te/gvm linked by @AquaL1te as well as the instructions provided by @Virsacer are using the latest available release 20.08.0 of GSA from the initial release of GVM-20.08 in August 2020.

This might explain why @greenbone/gsa-dev can't reproduce this as the changes are high it was already fixed in one of the 136 commits done to the gsa-20.08 branch in between:

v20.8.0...gsa-20.08

Instead of using the v20.08.0 release:

https://github.com/greenbone/gsa/archive/v20.8.0.tar.gz

you might want to give the 20.08 stable / release branch a try which contains quite a lot fixes:

https://github.com/greenbone/gsa/archive/gsa-20.08.zip

[Virsacer]

Well I have also tried it with the git versions in the past but with the same results...

You can change the download urls (and the directory names) - the rest of the instructions still applies

[bjoernricks]

I've just build all components from scratch (using all 20.08 release branches) again and I am still not able to reproduce the error.

Differences on my side:

• Dedicated install prefix (-DCMAKE_INSTALL_PREFIX=...)
• Dedicated user to build and run all components (not using root at all)
• Didn't run gvmd --rebuild-scap because that shouldn't be necessary at all
• Run gvmd and gsad with unix domain sockets instead of using tcp for their connection (omitting --listen=0.0.0.0 for gvmd and --mlisten=127.0.0.1 for gsad

So could somebody else please verify that the issue still occurs with using the release branches?

[Virsacer]

* Dedicated user to build and run all components (not using root at all)

Ok, that's it!
I tested with 20.8.0 release and 20.08 branch:
Running ospd-openvas and/or gvmd as root causes the error :-)

[gmottram]

I too am having this problem and I have been able to drill down into its cause, to a point.

I regenerated the main.*.chunk.js JavaScript code without it being minified and the issue is originating in "gsa-20.8.0/gsa/src/web/pages/reports/row.js". I installed from the version 20.8 tar ball on Debian 10 but I checked the latest version of row.js and it has not changed.

Lines 94-103 of row.js looks like this:

const Row = ({
  actionsComponent: ActionsComponent = Actions,
  entity,
  links = true,
  ...props
}) => {
  const {report} = entity;
  const {scan_run_status, task} = report;

  let status = scan_run_status;

The code is expecting "entity" to contain an element named "report" but when you run the system in a web browser, "entity" is the report and does not contain an element called "report".

This is the main.*.chunk.js code:

var reports_row_Row = function Row(_ref2) {
    var _ref2$actionsComponen = _ref2.actionsComponent,
          ActionsComponent = _ref2$actionsComponen === void 0 ? reports_row_Actions : _ref2$actionsComponen,
          entity = _ref2.entity,
          _ref2$links = _ref2.links,
          links = _ref2$links === void 0 ? true : _ref2$links,
          props = Object(objectWithoutProperties["a" /* default */])(_ref2, ["actionsComponent", "entity", "links"]);
          var report = entity.report;
          var scan_run_status = report.scan_run_status,
                 task = report.task;
          var status = scan_run_status;

However, the "entity" structure as seen in the JavaScript debugger looks like this:

entity: {…}
​​    content_type: "text/xml"
​​    creationTime: {…}
​​    entityType: "report"
​​    id: "f357ccc0-363d-4f27-b1c4-4b96b4d3839d"
​​    inUse: false
​    ​modificationTime: {…}
​​    name: "2020-12-15T04:40:12Z"
​​    owner: {…}
​​    report_format: {…}
​​    report_type: undefined
​​    scan_start: undefined
​​    task: {…}
​​    timestamp: undefined
​​    userCapabilities: {…}
​​    userTags: []
​    writable: 0
​​    <prototype>: {…}

​
The system bombs one the second of the following two lines in "main.*.chunk.js":

    var report = entity.report;
    var scan_run_status = report.scan_run_status,

The variable "report" is undefined because "entity" does not contain an element named "report" -- it is the report. The code would work if "var report = entity" instead of "var report = entity.report" but the larger cause seems to be how React is parsing the response from the gsa server. This is a snippet of the XML being returned by "get_reports" command:

<get_reports>
    <get_reports_response status="200" status_text="OK">
      <report id="f357ccc0-363d-4f27-b1c4-4b96b4d3839d" format_id="a994b278-1f62-11e1-96ac-406186ea4fc5" extension="xml" content_type="text/xml">
        <owner>
          <name>admin</name>
        </owner>
        <name>2020-12-15T04:40:12Z</name>
        <comment/>
        <creation_time>2020-12-15T04:40:12Z</creation_time>
        <modification_time>2020-12-15T06:45:19Z</modification_time>
        <writable>0</writable>
        <in_use>0</in_use>
        <task id="971a7b56-aca4-4c3c-ad44-4dc4855da6ae">
          <name>Test - Full and Fast</name>
        </task>
        <report_format id="a994b278-1f62-11e1-96ac-406186ea4fc5">
          <name>XML</name>
        </report_format>
      </report>

Based on the comments by the Greenbone staff not being able to reproduce the error I suspect the React parser is working differently for Greenbone than those of us having this issue. I would expect that that I am using a different Debian package for some component of the build that works differently from how it works on the Greenbone development machines. Alternately, is gsad supposed to return a <report> element within the <report id="..."> element?

I am not fluent in React and yarnpkg, so the solution may be obvious to someone who is. Oddly, as others have pointed out, everything else is working (I can click on the Results menu item and see the results of the scans). Any thoughts would be appreciated.

Thanks.

[gmottram]

SOLVED:

There is a permission problem on the following directory:

INSTALL_DIR/var/lib/gvm/gvmd/report_formats

The missing <report> elements within the outer <report id="..."> are created by the report formatting scripts. These scripts could not run because the above directory has no read or execute permissions for anyone but the directory owner. The scripts are run as "nobody" in "nogroup".

Solution:

Run the following command:

chmod 755 INSTALL_DIR/var/lib/gvm/gvmd/report_formats

You do not need to restart any Greenbone components. The fix will take effect immediately.

[Virsacer]

Run the following command:

chmod 755 INSTALL_DIR/var/lib/gvm/gvmd/report_formats

You do not need to restart any Greenbone components. The fix will take effect immediately.

Nice!

...and when you change the permission back to 700 the error apears again :-D
So THIS is the solution. Thank you!

GVMD probably should set the permission upon creation to prevent further users from running into this pitfall...

[bjoernricks]

https://community.greenbone.net/t/fix-for-reports-not-displaying-in-gvm-20-8-due-to-javascript-errors/7905 for a summary of this issue.

[bjoernricks]

Thanks all for your patience.

Because the root cause has been found I am closing this issue. We are going to add some patches to gvmd to improve the situation and make the debugging easier in future.

[jfortier-haptiq]

Great timing on this fix, was hoping to make a presentation at work on GSA soon, but couldn't figure this one out. Thanks @gmottram

[cfi-gb]

We are going to add some patches to gvmd to improve the situation and make the debugging easier in future.

Reference to the related improvements on gvmd side: greenbone/gvmd#1383

[kees-closed]

Side note for others, also make sure the disk is not mounted with e.g. noexec. I had this mistake, my container used persistence storage on a partition with noexec as mount option.