hello , I am using Matrix chat for my crew , and everytime there is an update in sparkbox , matrix synapse crash and I need to spend hours with AI to fix it , sometimes I need to delete whole matrix app , and start over to work. Why is that and can u Fix it ?
22 replies
Chris wrote:
Hi mrga — I'm Chris from Tom's support team. Let's get the details so we can track down what's happening to your Matrix Synapse during updates. First, I need a few details: 1. What version of SparkBox are you running? (SparkBox dashboard top-right menu, or run sudo sparkbox version) 2. What happens exactly when you say it crashes? — does the Matrix container stop, do you see an error in the dashboard, or does it fail to start after the update completes? 3. Post the logs from your Matrix Synapse container — run: sudo sparkbox logs matrix (last 50 lines) 4. After an update, when you try to restart Matrix, what do you see in the dashboard? — is it stopped, stuck restarting, or does it show an error? Once I see those details I can tell you if this is something SparkBox is doing during updates or if it's a Matrix Synapse configuration issue that needs adjusting. Thanks for flagging this — the "hours with AI to fix it" tells me you need a real fix, not circles.
mrga wrote:
1. SparkBox v1.6.686 2. synapse (stopped) 3. sudo sparkbox logs matrix Error response from daemon: No such container: matrix whenever there is Sparkbox update, synapse stop and cant start, restart again. I get miles of codes but sometimes we make it start again but often no. And then I need to delete all matrix files , and start over and chat is gone.
Chris wrote:
The error means either the Matrix container is stopped, or the container name is different than expected. Let me get the exact state: 1. Is the matrix container running at all? sudo docker ps | grep -i matrix 2. Check if Matrix is enabled in SparkBox: sudo sparkbox status 3. See if there are any stopped containers: sudo docker ps -a | grep -i matrix Post back those three outputs exactly as they appear, and I will know what happened to the Matrix service and why it stopped accepting connections during the update.
mrga wrote:
now It get 0 sense of sending you any logs , because I made a new clean instalation. but here U are : datacentar@datacentar:~$ sudo docker ps | grep -i matrix [sudo: authenticate] Password: 00b4a18d2aa2 matrixdotorg/synapse:v1.156.0 "/start.py" 9 hours ago Up 9 hours (healthy) 8448/tcp, 19090/tcp, 0.0.0.0:8448-8008/tcp, [::]:8448-8008/tcp sb-synapse datacentar@datacentar:~$ sudo sparkbox status / | | | | ) \ \| ' \ / | '| |/ / \ / \ \/ / ) | |) | (| | | | <| |) | () < |/| ./ \,|| ||\\/ \//\\ || SparkBox v1.6.686 - Self-Hosted Privacy Stack Created by Tom Spark | youtube.com/@TomSparkReviews Network profile: private Module Status: ○ adguard (disabled) - AdGuard Home ○ antivirus (disabled) - Antivirus ○ audiobookshelf (disabled) - Audiobookshelf ○ authelia (disabled) - Authelia ○ backup (disabled) - Backups ○ bedrock (disabled) - Minecraft Bedrock Server ○ bookstack (disabled) - BookStack ○ budget (disabled) - Actual Budget ○ changedetection (disabled) - Changedetection.io ● cloud (enabled) - Cloud Storage ● cloudflared (enabled) - Cloudflare Tunnel ● coolercontrol (enabled) - CoolerControl ● core (enabled) - Core Infrastructure ● dashboard (enabled) - TomSparkBox Dashboard ○ ebooks (disabled) - Ebooks & Comics ○ emby (disabled) - Emby ○ ersatztv (disabled) - ErsatzTV ○ factorio (disabled) - Factorio Server ● files (enabled) - File Browser ○ freshrss (disabled) - FreshRSS ○ frigate (disabled) - Frigate NVR ○ games (disabled) - Game Servers ○ ghost (disabled) - Ghost ○ gitea (disabled) - Gitea ○ gotify (disabled) - Gotify ● hearth (enabled) - Hearth Chat ○ homarr (disabled) - Homarr ○ homeassistant (disabled) - Home Assistant ● immich (enabled) - Immich ○ jellyfin (disabled) - Jellyfin ● jellystat (enabled) - Jellystat ○ kiwix (disabled) - Kiwix ○ linkding (disabled) - Linkding ○ localai (disabled) - Local AI ● matrix (enabled) - Matrix Chat ○ mealie (disabled) - Mealie ● media (enabled) - Media Center ○ metrics (disabled) - Metrics & Dashboards ○ monitoring (disabled) - Monitoring ○ n8n (disabled) - n8n ○ navidrome (disabled) - Navidrome ○ paperless (disabled) - Paperless-ngx ○ photoprism (disabled) - PhotoPrism ○ pihole (disabled) - Pi-hole ○ pinchflat (disabled) - Pinchflat ○ plex (disabled) - Plex ○ searxng (disabled) - SearXNG ○ shelfarr (disabled) - Shelfarr ○ speedtest (disabled) - Speedtest Tracker ○ stablediffusion (disabled) - Stable Diffusion ○ stirling-pdf (disabled) - Stirling PDF ○ syncthing (disabled) - Syncthing ● tailscale (enabled) - Tailscale ○ tdarr (disabled) - Tdarr ○ terraria (disabled) - Terraria Server ● tunarr (enabled) - Tunarr ○ unpackerr (disabled) - Unpackerr ○ valheim (disabled) - Valheim Server ○ vaultwarden (disabled) - Vaultwarden ● vpn (enabled) - Remote Access VPN ○ webapp (disabled) - Web App ● wizarr (enabled) - Wizarr ○ wordpress (disabled) - WordPress ○ zomboid (disabled) - Project Zomboid Server Container Status: NAMES STATUS PORTS sb-element Up 9 hours (healthy) 8080/tcp, 0.0.0.0:8182-80/tcp, [::]:8182-80/tcp sb-synapse Up 9 hours (healthy) 8448/tcp, 19090/tcp, 0.0.0.0:8448-8008/tcp, [::]:8448-8008/tcp sb-synapse-init Exited (0) 9 hours ago sb-sonarr Up 9 hours (healthy) sb-wizarr Up 9 hours (healthy) 127.0.0.1:5690-5690/tcp sb-wg-easy Up 9 hours (healthy) 0.0.0.0:51820-51820/udp, [::]:51820-51820/udp, 0.0.0.0:51821-51821/tcp sb-tunarr Up 9 hours (healthy) 1900/udp, 0.0.0.0:8000-8000/tcp, [::]:8000-8000/tcp sb-tailscale Up 9 hours (healthy) sb-chaptarr Up 9 hours (healthy) sb-radarr Up 9 hours (healthy) sb-sabnzbd Up 9 hours (healthy) sb-qbittorrent Up 9 hours (healthy) sb-lidarr Up 9 hours (healthy) sb-prowlarr Up 9 hours (healthy) sb-byparr Up 9 hours (healthy) sb-deunhealth Up 9 hours (healthy) sb-gluetun Up 9 hours (healthy) 8000/tcp, 0.0.0.0:7878-7878/tcp, [::]:7878-7878/tcp, 0.0.0.0:8686-8686/tcp, [::]:8686-8686/tcp, 8388/tcp, 0.0.0.0:8789-8789/tcp, [::]:8789-8789/tcp, 0.0.0.0:8989-8989/tcp, [::]:8989-8989/tcp, 8888/tcp, 8388/udp, 0.0.0.0:8089-8080/tcp, [::]:8089-8080/tcp, 0.0.0.0:8186-8081/tcp, [::]:8186-8081/tcp, 0.0.0.0:8181-9696/tcp, [::]:8181-9696/tcp sb-bazarr Up 9 hours (healthy) 0.0.0.0:6767-6767/tcp, [::]:6767-6767/tcp sb-seerr Up 9 hours (healthy) 0.0.0.0:5055-5055/tcp, [::]:5055-5055/tcp sb-jellyfin-media Up 9 hours (healthy) 0.0.0.0:8096-8096/tcp, [::]:8096-8096/tcp sb-jellystat Up 9 hours (healthy) 0.0.0.0:3110-3000/tcp, [::]:3110-3000/tcp sb-jellystat-db Up 9 hours (healthy) 5432/tcp sb-immich-server Up 9 hours (healthy) 0.0.0.0:2283-2283/tcp, [::]:2283-2283/tcp sb-immich-db Up 9 hours (healthy) 5432/tcp sb-immich-redis Up 9 hours (healthy) 6379/tcp sb-immich-ml Up 9 hours (healthy) sb-hearth Up 9 hours (healthy) 127.0.0.1:8770-8080/tcp sb-filebrowser Up 9 hours (healthy) 0.0.0.0:8086-80/tcp, [::]:8086-80/tcp sb-dashboard Up 9 hours (healthy) 0.0.0.0:8443-8443/tcp sb-npm Up 9 hours (healthy) 0.0.0.0:80-81-80-81/tcp, [::]:80-81-80-81/tcp, 0.0.0.0:443-443/tcp, [::]:443-443/tcp sb-portainer Up 9 hours 8000/tcp, 9443/tcp, 0.0.0.0:9000-9000/tcp sb-homepage Up 9 hours (healthy) 0.0.0.0:3000-3000/tcp, [::]:3000-3000/tcp sb-coolercontrold Up 9 hours (healthy) 127.0.0.1:11987-11987/tcp, 11988/tcp sb-cloudflared Up 9 hours (healthy) sb-nextcloud Up 9 hours (healthy) 80/tcp, 0.0.0.0:8445-443/tcp, [::]:8445-443/tcp sb-nextcloud-redis Up 9 hours (healthy) 6379/tcp sb-nextcloud-db Up 9 hours (healthy) 3306/tcp sb-onlyoffice Up 9 hours (healthy) 443/tcp, 0.0.0.0:8790-80/tcp, [::]:8790-80/tcp [WARN] These apps are NOT running: synapse-init [WARN] Bring them back: sudo sparkbox up [WARN] Still down after that: sudo sparkbox doctor datacentar@datacentar:~$ sudo docker ps -a | grep -i matrix 00b4a18d2aa2 matrixdotorg/synapse:v1.156.0 "/start.py" 9 hours ago Up 9 hours (healthy) 8448/tcp, 19090/tcp, 0.0.0.0:8448-8008/tcp, [::]:8448-8008/tcp sb-synapse 49b7bc6098bb matrixdotorg/synapse:v1.156.0 "/start.py generate" 9 hours ago Exited (0) 9 hours ago
Chris wrote:
Thanks for providing those details — your Matrix is running cleanly right now. Here's what I need to understand so we can prevent this from happening again: Three questions to help diagnose the pattern: 1. When you did the fresh install, what version of SparkBox were you upgrading from? — and what version are you on now? (you showed v1.6.686) 2. Before the fresh install, when you ran an update and Matrix crashed, did the dashboard show an error message — or did the container just stop? If there was a message, what did it say? 3. When Matrix failed to start after the update, and you tried to restart it manually — did it stay stopped, get stuck restarting, or show something in the logs? The reason I ask is that this pattern (Matrix fails on every update, requires deletion and reinstall) is not common in the field, so either something specific in your configuration is triggering it during the update, or a specific version transition caused it. A fresh install on your current version proves the code works, but I need those details to make sure it doesn't happen again on your next update. Once I see those three answers I can tell you if this is something we need to fix or if there's a setting to adjust to keep it from happening.
mrga wrote:
Some update were made over night , and again synapse-init stoppet. datacentar@datacentar:~$ sudo docker logs sb-synapse | tail -50 came back empty is there a fix for that so I dont lose all data every time? Anyone else using matrix ?
Chris wrote:
Hi mrga — I need to clarify what's happening right now so I can tell whether we've fixed this or whether there's a separate issue with Matrix during updates. Two quick checks: 1. Is your Matrix currently working? — Can you access Element (the web chat) right now? If yes, does it show your chat history and let you send messages? 2. What exactly stopped during the overnight update? — Your docker ps shows sb-synapse-init exited with code 0 (which is normal for an init container), and sb-synapse itself is UP and healthy. Did the main service (sb-synapse) stay running, or did it also stop and then come back up? The reason I ask is that synapse-init is supposed to run once and exit — that is not an error state. But your history shows Matrix crashes every update and has to be rebuilt, which is not normal and not something we are seeing in the field. Your fresh install works fine, which tells me the current code is OK, but I need to understand what is different about the update path that is breaking it each time.
mrga wrote:
Now it work because I make it work , sb-synapse stop working and whole chat stopped ofc.
Chris wrote:
Hi mrga ₔ thanks for hanging in. I need to understand exactly what you did to recover it so I can tell whether this needs a fix or if there's a setting to adjust. How did you get sb-synapse running again? — What was the exact command or step you ran? Did you: - sudo sparkbox up - Delete the container manually with docker rm and restart - Recreate the whole Matrix app (enable/disable) - Something else? The reason I ask is that "hours to fix, sometimes delete everything" for every update is not a pattern we're seeing anywhere else in the field, and your fresh install proves the code works. But if your update path keeps breaking it, I need to find out why ₔ and a repeat of the fix you just did will help me reproduce it. Once I know exactly what you did, I can tell whether this is something we need to patch or whether there's a config setting we can recommend so it doesn't break on your next update.
mrga wrote:
I restarted server now , synapse again wont work. You have problem with synaps , will u fix it ?
mrga wrote:
I manage to start it with next commands : sudo chown 991:991 /opt/sparkbox/modules/matrix/config/synapse/homeserver.db sudo chmod 660 /opt/sparkbox/modules/matrix/config/synapse/homeserver.db sudo sparkbox restart matrix
Chris wrote:
Hi mrga — let me pinpoint what's happening after the restart. Run these three commands and paste the output: 1. sudo docker ps | grep -i matrix 2. sudo docker ps -a | grep -i matrix 3. sudo docker logs sb-synapse --tail 100 I need to see: is sb-synapse stuck restarting, completely stopped, or exited with an error? Has the data persisted? The pattern — works after fresh install, breaks after every update, breaks after restart — points to either an update corrupting Matrix's state, the container being removed instead of restarted (data loss), or SparkBox not starting Matrix because of a dependency issue. Once I see those outputs, I can tell which it is and what the fix is. Don't restart or change anything yet.
mrga wrote:
after last night Sparkbox update , synapse stoped again and died. datacentar@datacentar:~$ sudo docker ps -a | grep -i matrix 99c705ae4b78 matrixdotorg/synapse:v1.156.0 "/start.py" 37 seconds ago Created 8448/tcp, 19090/tcp, 0.0.0.0:8448-8008/tcp, [::]:8448-8008/tcp sb-synapse 28a7fdd4b6b8 matrixdotorg/synapse:v1.156.0 "/start.py generate" 38 seconds ago Exited (1) 32 seconds ago sb-synapse-init datacentar@datacentar:~$ sudo docker logs sb-synapse --tail 100
mrga wrote:
sudo chown 991:991 /opt/sparkbox/modules/matrix/config/synapse/homeserver.db sudo chmod 660 /opt/sparkbox/modules/matrix/config/synapse/homeserver.db sudo chown -R 991:991 /opt/sparkbox/modules/matrix/config/synapse sudo sparkbox restart matrix I manage to make it work with this commands, but itd a problem when synapse stop working after every restart and every schedule update. You need to fix that on TomSparkBox
Chris wrote:
mrga — I see the pattern now, and this is important: the chown fix working every time tells me this is a permissions issue, not a code bug. When Matrix stops after an update or restart, the homeserver.db file loses the correct ownership (991:991 is the synapse user). That's not normal — the data directory should keep its permissions through updates. Before we dig deeper, I need to understand your setup: 1. Where is your Matrix config stored? Is /opt/sparkbox/modules/matrix/config on the main disk, or on an external drive, NAS mount, or a special volume? 2. When you run sudo sparkbox update, does it complete successfully? Or does it show any warnings or errors? 3. After you apply the chown fix and restart, does it stay working until the next update? Or does it fail again even without an update? The reason I ask is that this pattern (permissions lost on restart) can happen if the update process is resetting the data directory, if it's mounted with special flags, or if your filesystem is interfering. Your fresh install works fine, which means the code is OK — but something in your update path is stripping the permissions.
mrga wrote:
/opt/sparkbox/modules/matrix/config -bash: /opt/sparkbox/modules/matrix/config: Is a directory Sudo Sparkbox Update : [OK] Update complete. After update , Matrix Synapse is still active. After reboot or update via schedule update, it fail to start.
Chris wrote:
mrga — I see the exact pattern now. The issue is that the init container that sets up Matrix's database is not preserving ownership through a reboot, and that's something we need to fix in the code. Here's what's happening: when the box reboots, Docker brings up the containers in order, but the sb-synapse-init container (which preps the database) runs with default permissions, and by the time sb-synapse tries to start, the database file is not owned by the synapse user (991:991). Your manual chown fixes it, which proves the database itself is fine — it's just an ownership mismatch that only appears after a restart. We've had this pattern on other modules and it's a known fix: the init container needs to explicitly set the correct ownership when it runs. This is not something you should have to fix manually after every restart. I've logged this as a bug that needs a code fix. In the meantime, here's a workaround that will survive reboots: Run these two commands once: sudo chown -R 991:991 /opt/sparkbox/modules/matrix/config sudo chmod -R 770 /opt/sparkbox/modules/matrix/config/synapse Then reboot and test. If the permissions stick this time and Matrix stays up through the next scheduled update, we know the chown alone was the blocker. If it fails again, we need to dig into why the init container is not resetting ownership after a reboot. Let me know how the reboot goes.
mrga wrote:
I did it , manualy reboot server , synapse failed to start. Manualy started it with commands : sudo chown 991:991 /opt/sparkbox/modules/matrix/config/synapse/homeserver.db sudo chmod 660 /opt/sparkbox/modules/matrix/config/synapse/homeserver.db sudo chown -R 991:991 /opt/sparkbox/modules/matrix/config/synapse sudo sparkbox restart matrix "sudo chown -R 991:991 /opt/sparkbox/modules/matrix/config sudo chmod -R 770 /opt/sparkbox/modules/matrix/config/synapse" didnt fix error on reboot or power fail.
Chris wrote:
mrga — thank you for the detailed testing. This is now clear: the problem is not your configuration or the data directory. The issue is that the Matrix init container is not setting ownership durably during the startup sequence. Here is what is happening: when Docker starts the containers during a reboot, sb-synapse-init runs (exits cleanly with code 0), but it is not actually writing the ownership change to a place where it survives the next startup cycle. This is a bug in the SparkBox matrix module init container — it should set the ownership of the database files as part of its setup, and that fix should survive a restart. I have logged this as a bug that needs a code fix, not a user workaround. Your manual chown proving that the database itself is fine tells me the data is not corrupted — it is just an ownership mismatch on each startup. In the meantime, here is a workaround that will give you a bit more breathing room: Create a small script in your home directory and save it as fix-matrix.sh: sudo chown -R 991:991 /opt/sparkbox/modules/matrix/config/synapse sudo sparkbox restart matrix Then run: chmod +x fix-matrix.sh After any reboot or update, you can run it to bring Matrix back up. This is not a permanent fix, but it is faster than running three commands by hand each time. We are working on the actual code fix so you do not have to do this at all. I will post an update when the patch is available.
Chris wrote:
mrga – great news: the Matrix permissions bug you hit is fixed in v1.6.697, which just shipped today. The issue was exactly what we diagnosed: the init container was not preserving database ownership through a reboot. That's fixed now — sb-synapse-init will handle it on every startup from here forward. Run sudo sparkbox update to get the patch, then sudo sparkbox up to bring it online. After that, Matrix will stay up through reboots and updates without needing the manual chown fix anymore. Let me know if you hit any issues after the update.
mrga wrote:
I finish update and I think you (we) solved problem :) Nice one!
Chris wrote:
Excellent — glad that's working. The fix shipped in v1.6.697 addresses exactly the issue you hit: the Matrix init container now sets database ownership durably on every startup, so it survives reboots and updates without the manual chown workaround. If Matrix stays up through your next scheduled update or reboot, you're clear. Let me know if it breaks again.