Wenn in Matrix-Räumen gar nichts mehr funktioniert – keine Nachrichten mehr ankommen, das Verlassen des Raumes nicht möglich ist und stattdessen eine Fehlermeldung wie MatrixError: [403] No create event in auth events erscheint – dann ist meistens der lokale Raum-State beschädigt.

Der Synapse-Server erkennt das „m.room.create“-Event nicht mehr und verweigert dadurch sämtliche Aktionen. Hier zeige ich, wie man solche sogenannten Zombie-Räume loswird – egal ob mit Docker betrieben oder auf einem klassischen Server installiert. Genau das ist mir mit dem Support-Raum von matrix-docker-ansible-deploy passiert. Da meine Installation in Docker-Containern läuft, können die Befehle bei anderen Setups eventuell abweichen.

In Clients wie Element werden diese Räume weiterhin als aktiv angezeigt, es kommen aber keine Nachrichten mehr an, und auch das Verlassen schlägt fehl. In den Logs findet sich dann eine Zeile wie:

MatrixError: [403] No create event in auth events

Das Problem liegt folglich nicht im Client, sondern im Synapse-Backend. Dem Server fehlt das m.room.create-Event, daher weiß er nicht mehr, dass der Raum existiert.

Um die Raum-ID zu ermitteln, gibt es verschiedene Wege – abhängig davon, ob du Server-Zugang oder nur den Client verwendest.

• Über den Synapse Admin-Client: Öffne in Synapse Admin (Weboberfläche unter https://deinserver/_synapse/) den entsprechenden Raum. Die Raum-ID findest du in der Adresszeile der URL – sie beginnt immer mit einem Ausrufezeichen, etwa !cNSQwPqhHKkIZdBnvt:devture.com.

• Über die API: Du kannst aus dem Container heraus eine Suche nach Räumen durchführen:

      docker exec -i matrix-synapse \
        curl -sS "http://localhost:8008/_synapse/admin/v1/rooms?search_term=raumname" \
        -H "Authorization: Bearer " | jq 

  Damit findest du die vollständige Room-ID auch ohne Client.

• Über den Matrix-Client (wie Element): Gehe in die Raumdetails und schau unter „Erweiterte Informationen“ – dort wird die Room-ID ebenfalls angezeigt.

Die Raum-ID benötigst du für alle Befehle der Admin-API, da Synapse im Hintergrund nicht mit Aliasen (wie #meinraum:matrixbox.de), sondern ausschließlich mit der eindeutigen Room-ID arbeitet.

Dies tritt typischerweise auf bei:

• unterbrochenen Föderations-Synchronisationen
• beschädigten Datenbankeinträgen
• veralteten Synapse-Versionen (unter 1.90), die State-Resets nicht korrekt verarbeiten

Auswirkung: Der Raum ist teilweise funktionslos. Sichtbar, aber nicht mehr nutzbar.

Am einfachsten ist die Bereinigung über die Admin-API, nicht über das Webinterface. Den erforderlichen Admin-Token findet ihr im Element-Client unter Einstellungen » Hilfe und Info (Access Token des Administrators).

Synapse läuft normalerweise im Container mit dem Namen matrix-synapse. Steigt in den Container ein und führt den Löschbefehl aus:

docker exec -i matrix-synapse \
  curl -sS -X DELETE "http://localhost:8008/_synapse/admin/v2/rooms/%21cNSQwPqhHKkIZdBnvt%3Adevture.com" \
  -H "Authorization: Bearer " \
  -H "Content-Type: application/json" \
  -d '{"purge":true,"block":true,"force_purge":true}'

Dadurch wird der Raum endgültig aus der Datenbank entfernt und gleichzeitig gesperrt, sodass kein erneuter Beitritt möglich ist. Die API gibt eine delete_id zurück, mit der sich der Löschstatus prüfen lässt:

docker exec -i matrix-synapse \
  curl -sS "http://localhost:8008/_synapse/admin/v2/rooms/delete_status/" \
  -H "Authorization: Bearer "

Warte, bis der Status auf complete steht.

Im Element-Client: Einstellungen → Hilfe → Cache leeren und neu laden

Der Raum wird daraufhin aus der Übersicht entfernt.

Wenn du beim Löschen block:true gewählt hast (empfohlen), musst du die Sperre bei Bedarf manuell aufheben, bevor ein erneuter Beitritt möglich ist.

docker exec -i matrix-synapse \
  curl -sS -X PUT "http://localhost:8008/_synapse/admin/v1/rooms/%21cNSQwPqhHKkIZdBnvt%3Adevture.com/block" \
  -H "Authorization: Bearer " \
  -H "Content-Type: application/json" \
  -d '{"block": false}'

Anschließend kann der Raum wie gewohnt wieder beigetreten werden, beispielsweise so:

curl -sS -X POST \
  "https://matrix.matrixbox.de/_matrix/client/v3/rooms/%21cNSQwPqhHKkIZdBnvt%3Adevture.com/join?server_name=devture.com" \
  -H "Authorization: Bearer " \
  -d '{}'

Damit die Admin-APIs künftig auch außerhalb des Containers erreichbar sind, sollte nginx sowohl /_matrix als auch /_synapse an Synapse weiterleiten:

location ~ ^/(_matrix|_synapse/client) {
    proxy_pass http://synapse:8008;
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
    proxy_request_buffering off;
}

Danach einfach nginx -t && systemctl reload nginx ausführen.

Wenn Räume bei Matrix hängen bleiben, liegt das fast immer an einem fehlerhaften Raum-State auf dem Homeserver und selten am Client. Mittels Admin-API lässt sich das zuverlässig beheben – mit neueren Synapse-Versionen (ab 1.110) treten solche Probleme zudem wesentlich seltener auf.