Failed to create the testing environment: Resource with UUID '' does not exist

[Jörg Schin.]

Hi,

today I set up a new Wazuh 5.0 Beta instance on Ubuntu 24.04. Since the new installation, it is no longer possible to promote an existing decoder with an existing integration from draft to test, either via the GUI or via curl.

Maybe it's a known issue or i did anything wrong, idk

Additionally, since today I have been seeing the following status in the health check:

integrations:default-notifications-channels yellow finished

Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]: Security Analytics - IntegrationService - promoteIntegration: StatusCodeError: Bad Request
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:     at respond (/usr/share/wazuh-dashboard/node_modules/elasticsearch/src/lib/transport.js:349:15)
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:     at checkRespForFailure (/usr/share/wazuh-dashboard/node_modules/elasticsearch/src/lib/transport.js:306:7)
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:     at HttpConnector.<anonymous> (/usr/share/wazuh-dashboard/node_modules/elasticsearch/src/lib/connectors/http.js:173:7)
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:     at IncomingMessage.wrapper (/usr/share/wazuh-dashboard/node_modules/lodash/lodash.js:5022:19)
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:     at IncomingMessage.emit (node:events:531:35)
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:     at endReadableNT (node:internal/streams/readable:1698:12)
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:     at processTicksAndRejections (node:internal/process/task_queues:90:21) {
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   status: 400,
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   displayName: 'BadRequest',
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   path: '/_plugins/_content_manager/promote',
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   query: {},
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   body: {
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:     message: "Failed to create the testing environment: Resource with UUID '' does not exist",
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:     status: 400
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   },
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   statusCode: 400,
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   response: `{"message":"Failed to create the testing environment: Resource with UUID '' does not exist","status":400}`,
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   toString: [Function (anonymous)],
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]:   toJSON: [Function (anonymous)]
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]: }
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]: {"type":"response","@timestamp":"2026-07-09T13:31:37Z","tags":[],"pid":29432,"method":"post","statusCode":200,"req":{"url":"/_plugins/_security_analytics/integrations/promote?dataSourceId=","routePath":"/_plugins/_security_analytics/integrations/promote","method":"post","headers":{"host":"IPv4","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0","accept":"*/*","accept-language":"de,en-US;q=0.9,en;q=0.8","accept-encoding":"gzip, deflate, br, zstd","referer":"https://IPv4/app/sa-integrations","content-type":"application/json","osd-version":"3.6.0","osd-xsrf":"osd-fetch","content-length":"300","origin":"https://IPv4","connection":"keep-alive","sec-fetch-dest":"empty","sec-fetch-mode":"cors","sec-fetch-site":"same-origin","priority":"u=0"},"remoteAddress":"192.168.60.38","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0","referer":"https://IPv4/app/sa-integrations"},"res":{"statusCode":200,"responseTime":50,"contentLength":9},"message":"POST /_plugins/_security_analytics/integrations/promote?dataSourceId= 200 50ms - 9.0B"}
Jul 09 13:31:37 wazuh5-0 opensearch-dashboards[29432]: {"type":"response","@timestamp":"2026-07-09T13:31:37Z","tags":[],"pid":29432,"method":"get","statusCode":200,"req":{"url":"/ui/logos/wazuh_mark_on_dark.svg","routePath":"/ui/{path*}","method":"get","headers":{"host":"IPv4","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0","accept":"image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5","accept-language":"de,en-US;q=0.9,en;q=0.8","accept-encoding":"gzip, deflate, br, zstd","connection":"keep-alive","referer":"https://IPv4/app/sa-integrations","sec-fetch-dest":"image","sec-fetch-mode":"no-cors","sec-fetch-site":"same-origin","priority":"u=5"},"remoteAddress":"192.168.60.38","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0","referer":"https://IPv4/app/sa-integrations"},"res":{"statusCode":200,"responseTime":4,"contentLength":9},"message":"GET /ui/logos/wazuh_mark_on_dark.svg 200 4ms - 9.0B"}

Greez

[Marcel Kemp]

Hi Jörg,

I’m not exactly sure whether this is a known issue or not; I’ll have a look at the issues and let you know.

In the meantime, I’d need to know which beta version you’re using, as if it’s Beta 2, it may have been fixed or improved in Beta 3.
And based on the problem, it seems it might be related to the lack of a root decoder, but I can’t say for certain.

[Jörg Schin.]

Hi again Marcel,

I’m using stage Beta 3.

No problem, take your time. I was able to fix the health check issue by creating a role called wazuh_notifications_access:

curl -k \ --cert /etc/wazuh-indexer/certs/admin.pem \ 

--key /etc/wazuh-indexer/certs/admin-key.pem \ 

-X PUT \ 

-H "Content-Type: application/json" \ 

https://localhost:9200/_plugins/_security/api/roles/wazuh_notifications_access \ 

-d '{ 

"cluster_permissions": [ "cluster:admin/opensearch/notifications/configs/get", "cluster:admin/opensearch/notifications/configs/*" ], "index_permissions": [], "tenant_permissions": [] 

}'

and assigning this role to the kibanaserver user:

curl -k \ 

--cert /etc/wazuh-indexer/certs/admin.pem \

 --key /etc/wazuh-indexer/certs/admin-key.pem \ 

 -X PUT \

 -H "Content-Type: application/json" \ 

https://localhost:9200/_plugins/_security/api/rolesmapping/wazuh_notifications_access \ 

-d '{

 "users": [ "kibanaserver" ] 

}'

Maybe this helps you :)

Here is my custom root decoder. Unfortunately, it was from an instance that has already been deleted, but it was working there:

---
enabled: true
metadata:
  author: "JSI"
  description: "Base decoder to process custom Wazuh message format."
  references:
  - "https://documentation.wazuh.com/"
  title: "Wazuh custom message decoder"
  date: "2026-07-09T13:26:10Z"
  modified: "2026-07-09T13:28:14Z"
  supports: []
name: "decoder/custom-core-wazuh-message/0"
normalize:
- map:
  - _tmp_json: "parse_json($event.original)"
id: "e43322ee-b446-4106-afa8-1cba4cd25a0e"

I will set up a new instance tomorrow using wazuh-install-5.0.0-beta3.sh. This worked the last time with the decoder.

This time, however, I have a manually installed version following this tutorial:
https://documentation.wazuh.com/5.0-beta/installation-guide/wazuh-indexer/step-by-step.html

Jörg Schin. schrieb am Donnerstag, 9. Juli 2026 um 16:28:19 UTC+2:

Hi again Marcel,

I’m using stage Beta 3.

No problem, take your time. I was able to fix the health check issue by creating a role called wazuh_notifications_access:

curl -k \ --cert /etc/wazuh-indexer/certs/admin.pem \ --key /etc/wazuh-indexer/certs/admin-key.pem \ -X PUT \ -H "Content-Type: application/json" \ https://localhost:9200/_plugins/_security/api/roles/wazuh_notifications_access \ -d '{ "cluster_permissions": [ "cluster:admin/opensearch/notifications/configs/get", "cluster:admin/opensearch/notifications/configs/*" ], "index_permissions": [], "tenant_permissions": [] }'

and assigning this role to the kibanaserver user:

curl -k \ --cert /etc/wazuh-indexer/certs/admin.pem \ --key /etc/wazuh-indexer/certs/admin-key.pem \ -X PUT \ -H "Content-Type: application/json" \ https://localhost:9200/_plugins/_security/api/rolesmapping/wazuh_notifications_access \ -d '{ "users": [ "kibanaserver" ] }'

Maybe this helps you :)

Here is my custom root decoder. Unfortunately, it was from an instance that has already been deleted, but it was working there:

--- enabled: true metadata: author: "JSI" description: "Base decoder to process custom Wazuh message format." references: - "https://documentation.wazuh.com/" title: "Wazuh custom message decoder" date: "2026-07-09T13:26:10Z" modified: "2026-07-09T13:28:14Z" supports: [] name: "decoder/custom-core-wazuh-message/0" normalize: - map: - _tmp_json: "parse_json($event.original)" id: "e43322ee-b446-4106-afa8-1cba4cd25a0e"

I will set up a new instance tomorrow using wazuh-install-5.0.0-beta3.sh. This worked the last time with the decoder.

This time, however, I have a manually installed version following this tutorial:
https://documentation.wazuh.com/5.0-beta/installation-guide/wazuh-indexer/step-by-step.html

[Marcel Kemp]

It seems there are several known issues that appear to be related to your particular case; however, I believe they were merged after the Beta 3 tag, so they won’t be fixed until Beta 4:

• Allow null root_decoder when a policy has no integrations#37344
• Fix missing root decoder upon space reset#1333

[Jörg Schin.]

Thanks for looking into the issues, and it's good to know they've already been identified.

I'll wait for the next release then.

Best regards,