Hardware/DSM
Ausgangslage (vor dem Crash)
Wichtige Beobachtung zu Nextcloud AIO / Docker API
<span><span>ping </span><span><span>192.168</span></span><span>.</span><span><span>178.37</span></span><span><br></span></span>
Ergebnis: 4/4 Antworten, <1ms, TTL=64
<span><span>nslookup google.com </span><span><span>192.168</span></span><span>.</span><span><span>178.37</span></span><span><br></span></span>
Ergebnis:
<span><span><span>Test-NetConnection</span></span><span> </span><span><span>192.168</span></span><span>.</span><span><span>178.37</span></span><span> </span><span><span>-Port</span></span><span> </span><span><span>53</span></span><span><br></span></span>
Ergebnis:
Wenn ihr sagt, welche Logs/Ansichten ihr braucht: Ich kann Screenshots liefern (Synology Assistant Statuszeile, Login-Screen, ggf. Protokoll-Center Ereignisse).
- Modell: Synology DS224+
- DSM-Version (aus Synology Assistant): 7.3.2-86009
- LAN-IP der NAS: 192.168.178.37
- Client: Windows PC 192.168.178.150
- LED-Status: Power/ON/OFF blinkt blau, HDD-LEDs blinken.
Ausgangslage (vor dem Crash)
- Auf der DS224+ lief Docker/Container Manager mit Nextcloud AIO (mehrere AIO-Container).
- Es gab wiederholt Instabilitäten: Container Manager zeigte zeitweise 0 Container / 0 Images, danach wieder normal.
- CPU im Container Manager zeitweise sehr hoch (Skala ging bis 400%, dauerhaft hoch).
- In DSM Ressourcen-Monitor/Task Manager fielen sehr viele php-fpm Prozesse auf.
- Nextcloud Log hatte u. a. sehr lange DB-Transaktionen, z. B.:
- [no app in context] Warning: Transaction took ~304s (PROPFIND /remote.php/dav/ …)
- teils von externen IPs (z. B. 62.46.xxx.xxx / 91.114.xxx.xxx) – Zeitpunktbezug siehe unten.
Wichtige Beobachtung zu Nextcloud AIO / Docker API
- In den Container-Details vom AIO-Mastercontainer war als ENV sichtbar:
- DOCKER_API_VERSION = 1.43
- Der AIO „docker socket proxy“ / AppAPI Deploy Daemon war zeitweise deaktiviert – Crash trat trotzdem weiter auf.
Aktueller Zustand nach Neustart (Problem jetzt)
- DSM Web-Login geht nicht
- Beim Login (Benutzer kommt dauerhaft:
- „System wird vorbereitet. Melden Sie sich später an.“
- Das erscheint wiederholt, auch nach Wartezeit.
- Synology Assistant zeigt widersprüchlichen Zustand
- Synology Assistant listet:
- DS224 – IP 192.168.178.37 – DSM 7.3.2-86009
- Status/Spalte: „Nicht konfiguriert“
- Bei „Konfigurieren“ kommt ein Dialog:
- „Serverdaten eingeben“ mit Systemadministrator-Konto: admin + „Neues Passwort“ etc. (wirkt wie Erstkonfiguration).
- NAS ist im LAN erreichbar
- Ping ist sauber:
<span><span>ping </span><span><span>192.168</span></span><span>.</span><span><span>178.37</span></span><span><br></span></span>
Ergebnis: 4/4 Antworten, <1ms, TTL=64
- DNS-Dienst auf der NAS antwortet (wichtig wegen „kein Internet“ im LAN)
<span><span>nslookup google.com </span><span><span>192.168</span></span><span>.</span><span><span>178.37</span></span><span><br></span></span>
Ergebnis:
- Server: UnKnown (aber Adresse stimmt: 192.168.178.37)
- Nicht autorisierende Antwort
- google.com wird korrekt aufgelöst (IPv6 + IPv4 zurückgegeben)
- Port 53 TCP ist offen
<span><span><span>Test-NetConnection</span></span><span> </span><span><span>192.168</span></span><span>.</span><span><span>178.37</span></span><span> </span><span><span>-Port</span></span><span> </span><span><span>53</span></span><span><br></span></span>
Ergebnis:
- TcpTestSucceeded : True
Zeitbezug / Log-Beobachtung
- Nextcloud Logeinträge wie Transaction took …s traten auch zu Zeitpunkten auf, wo Outlook/CalDav Sync + iPhones ausgeschaltet waren (zumindest auf meiner Seite), z. B.:
- Jan 2, 2026 ~22:xx: admin_audit … / Capabilities …
- Jan 2, 2026 16:04: Transaction took 304…s PROPFIND /remote.php/dav/
Meine Fragen an die Community (bitte ohne Datenverlust)
- Wie interpretiert ihr die Kombination aus:
- DSM Login „System wird vorbereitet…“
- Synology Assistant: „Nicht konfiguriert“ + Passwort-neu setzen Dialog
- aber gleichzeitig: Ping/DNS/Port 53 funktionieren
- Was ist die sichere Vorgehensweise, um wieder in DSM reinzukommen, ohne dass bei „Konfigurieren“ versehentlich eine Neuinstallation/Reset gestartet wird?
- Gibt es bekannte Ursachen, dass DSM nach einem Crash in so einen „halb online“-Zustand geht (Dienste antworten, GUI blockiert)?
Wenn ihr sagt, welche Logs/Ansichten ihr braucht: Ich kann Screenshots liefern (Synology Assistant Statuszeile, Login-Screen, ggf. Protokoll-Center Ereignisse).
