Mkdtemp error after upgrading from 21.4.1 to 21.4.4

Archive Greenbone Community Edition
1

Hello,

After upgrading GVM from 21.4.1 to 21.4.4, I get an mkdtemp error whenever I try to access a report.
I’ve raised the debug level to 128, and I now have the following:

md main:MESSAGE:2021-09-14 10h42.38 utc:6634: Greenbone Vulnerability Manager version 21.4.4~dev1~git-70cb2d7be-gvmd-21.04 (GIT revision 70cb2d7be-gvmd-21.04) (DB revision 242)
libgvm util:MESSAGE:2021-09-14 10h42.39 utc:6635: Setting GnuPG dir to ‘/opt/gvm/var/lib/gvm/gvmd/gnupg’
libgvm util:MESSAGE:2021-09-14 10h42.39 utc:6635: Using OpenPGP engine version ‘2.2.4’
libgvm util:WARNING:2021-09-14 10h44.17 UTC:6688: gvm_file_copy: g_file_copy(/tmp/gvmd_9LHLGk/report-start.xml, /tmp/gvmd_9LHLGk/report.xml) failed - Error when getting information for file “/tmp/gvmd_9LHLGk/report-start.xml”: No such file or directory
md manage:WARNING:2021-09-14 10h44.17 UTC:6688: print_report_xml_end: failed to copy xml_start file
md manage:WARNING:2021-09-14 10h44.17 UTC:6688: manage_send_report: No such file or directory
libgvm util:WARNING:2021-09-14 10h44.17 UTC:6688: g_lstat(/tmp/gvmd_9LHLGk) failed - No such file or directory
md gmp: INFO:2021-09-14 10h44.17 UTC:6688: Failed to parse client XML: Internal Error.
md manage:WARNING:2021-09-14 10h44.55 UTC:6790: manage_send_report: mkdtemp failed

I’ve used all installation variables set in the documentation, but that doesn’t help. On my system, /tmp is fully writeable so it shouldn’t be a problem. Also, I’ve not seen any installation variable related to the TMP directory. So how/where is that installation variable set ? If it’s linked to INSTALL_PREFIX, then in my case it should be /opt/gvm/tmp, not /tmp.

Any clue ?

2

The error is that there is no report. Please check your logs, dmesg etc … why no report was created.

3

No; these reports exists and were available before update. Moreover, the error is:

manage_send_report: mkdtemp failed

Which indicate that the temp directory can’t be created. Either because permissions are incorrect or because the path doesn’t exist. And I’m pretty sure that’s the second option, because all those PATH issues were introduced in 21.4.3

4

So you need to strace the parent process to see what the exact error is. Good luck …
I would limit with “-o file” the amount of syscalls.