Matrix: Räume lassen sich nicht löschen oder verlassen – so rettest du deinen Homeserver

Wenn bei Matrix-Räumen gar nix mehr geht – Nachrichten bleiben aus, das Verlassen klappt nicht und stattdessen grüßt eine Fehlermeldung wie MatrixError: [403] No create event in auth events – dann ist meist der lokale Raum-State kaputt.

Das Problem hatte ich mit meinem privaten Matrixserver. Das Problem musste ich also irgendwie lösen. Wie ich das geschafft habe, erfahrt ihr hier in diesem Post. 

Der Synapse-Server findet den „m.room.create“-Event nicht mehr und weigert sich, irgendwas zu tun. Hier zeige ich, wie man solche Zombie-Räume loswird – egal ob im Docker-Setup oder auf einem klassischen Server. So ging es mir mit dem Supportraum von matrix-docker-ansible-deploy 
Da das System in Docker Containern läuft, können bei anderen Installationen und Anpassungen die Befehle anders sein.

Das Symptom

In Element oder anderen Clients sehen die Räume noch aktiv aus, aber es kommen keine Nachrichten mehr an, „Raum verlassen“ schlägt fehl und in den Logs steht etwas wie:

MatrixError: [403] No create event in auth events

Das Problem sitzt also nicht im Client, sondern im Synapse-Backend. Der Server weiß schlicht nicht mehr, dass der Raum existiert, weil ihm der m.room.create-Event fehlt.

Wie finde ich die Raum-ID?

Um die Raum-ID herauszufinden, gibt es mehrere Möglichkeiten – je nachdem, ob du Zugriff auf den Server oder nur den Client hast.

• Über den Synapse Admin-Client: In Synapse Admin (Weboberfläche unter https://deinserver/_synapse/) öffnest du den entsprechenden Raum, dann zeigt dir die URL in der Adresszeile die ID an – sie beginnt immer mit einem Ausrufezeichen, z. B. !cNSQwPqhHKkIZdBnvt:devture.com.
• Über die API: Du kannst im Container alle Räume durchsuchen:

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

  So findest du die vollständige Room-ID auch ohne Client.
• Über den Matrix-Client (z. B. Element): In den Raumdetails auf „Erweiterte Informationen“ klicken – dort steht die Room-ID ebenfalls.

Die Raum-ID brauchst du für alle Admin-API-Befehle, da Synapse intern nicht mit Aliasen (wie #meinraum:matrixbox.de), sondern mit der eindeutigen Room-ID arbeitet.

Ursache: Korruptes Raum-State

Das passiert typischerweise bei:

• abgebrochenen Föderations-Synchronisationen
• defekten Datenbank-Einträgen
• alten Synapse-Versionen (unter 1.90), die State-Resets nicht sauber abfangen

Die Folge: Der Raum ist halbtot. Man kann ihn sehen, aber nicht mehr anfassen.

Lösung: Mit der Admin-API aufräumen

Der einfachste Weg führt über die Admin-API, nicht über die GUI. Den Admin-Token bekommt ihr im InElement Client unter Einstellungen >> Hilfe und info. (Access Token des Admin-Nutzers)

1. Raum per API löschen

Bei matrix-docker-ansible-deploy läuft der Synapse-Container standardmäßig unter dem Namen matrix-synapse. Einfach in den Container springen und den Löschbefehl ausführen:

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}'

Damit wird der Raum komplett aus der Datenbank entfernt und gleichzeitig blockiert, sodass niemand wieder beitreten kann. Die API liefert eine delete_id zurück, an der du den Fortschritt abfragen kannst:

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.

2. Cache im Client leeren

In Element:
Einstellungen → Hilfe → Clear cache and reload

Danach ist der Raum aus der Liste verschwunden.

Wiederbeitritt blockiert? Kein Problem

Wenn du beim Löschen block:true gesetzt hast (was empfehlenswert ist), musst du den Raum später manuell entblocken, bevor du ihn wieder joinen kannst.

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}'

Danach kannst du ganz normal wieder beitreten, z. B. mit:

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

Tipp für nginx-User

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

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.

Fazit

Wenn Räume in Matrix hängen bleiben, ist das selten der Client, sondern fast immer ein kaputter Raum-State auf dem Homeserver. Mit der Admin-API lässt sich das Problem zuverlässig lösen – und mit aktuellen Synapse-Versionen (ab 1.110 und neuer) treten solche Fehler deutlich seltener auf.

Schlagwörter: matrix, synapse, docker, homeserver, fehlerbehebung
Kategorie: Matrix / Admin