Community-Lösung

ZimaClient findet ZimaOS im selben LAN nicht: Lokale Erkennung, mDNS und ein ungelöster Fall

An October 2025 thread where ZimaClient could connect through Remote ID but automatic LAN discovery returned No Device Found. iOS Local Network permission was enabled, Avahi was running, reinstalling ZimaOS did not help, and Android later failed too. The public thread ended without a confirmed root cause.

Dieser Fall trennt zwei Verbindungswege, die Nutzer häufig für dasselbe halten. ZimaClient konnte erfolgreich eine Verbindung herstellen, wenn der Nutzer die Remote-ID eingab – sowohl zu Hause als auch außerhalb des Heimnetzwerks. Die automatische Erkennung im lokalen Netzwerk zeigte jedoch Kein Gerät gefunden. Das bedeutet, dass die Serverzuordnung und der Remote-Zugriff funktionierten, während die lokale Erkennung fehlschlug.

Der Thread führte zu keiner bestätigten endgültigen Lösung. Die Berechtigung für das lokale Netzwerk unter iOS war bereits aktiviert, Avahi lief, eine vollständige Neuinstallation von ZimaOS änderte nichts am Verhalten, und der Nutzer installierte später den Android-Client – nur um festzustellen, dass auch Android den Server nicht automatisch erkennen konnte.

Remote-ID funktionierte, während die LAN-Erkennung fehlschlug

Zima Client auf einem iPhone zeigt „Kein Gerät gefunden“ mit einer Schaltfläche „Über Remote-ID verbinden“
Der Client konnte weiterhin die Remote-ID verwenden, fand aber automatisch kein Gerät im selben LAN.

Dieser Unterschied bildet eine nützliche diagnostische Grenze: Beheben Sie keine Probleme bei der Remote-ID-Authentifizierung, wenn der Fehler ausschließlich die lokale Erkennung betrifft.

Die Berechtigung für das lokale Netzwerk unter iOS war bereits aktiviert

Eine Antwort aus der Community empfahl richtigerweise, die iOS-Einstellungen zu überprüfen, da Apple für Apps, die Geräte im lokalen Netzwerk erkennen oder mit ihnen kommunizieren, eine ausdrückliche Berechtigung verlangt.

iOS-Einstellungen für das lokale Netzwerk zeigen, dass die Berechtigung für Zima Client aktiviert ist
Der Nutzer hatte Zima Client den Zugriff auf das lokale Netzwerk bereits erlaubt. Die grundlegende iOS-Datenschutzeinstellung war daher nicht die endgültige Erklärung.

Eine Neuinstallation der App und von ZimaOS behob das Problem nicht

Der Nutzer installierte die iOS-App wiederholt neu, startete das NAS neu und fuhr es herunter und formatierte und installierte schließlich ZimaOS neu. Keiner dieser Schritte stellte die automatische Erkennung wieder her.

Diese negativen Hinweise sprechen gegen einen einfachen veralteten App-Cache oder eine einzelne beschädigte ZimaOS-Installation.

Die Community vermutete mDNS/Bonjour

Die automatische Geräteerkennung vieler lokaler Anwendungen hängt von Multicast-DNS oder ähnlichen Broadcasts zur LAN-Erkennung ab. Community-Mitglieder vermuteten, dass der Client diese Ankündigungen nicht empfing, und empfahlen, die Client-Isolierung im Access Point sowie die Weiterleitung von Multicast-Daten zu überprüfen.

Der Nutzer widersprach, weil AirPrint, AirPlay, die QNAP-Erkennung und andere lokale iOS-Dienste über dasselbe TP-Link-Deco-Netzwerk funktionierten.

Avahi lief auf ZimaOS

ZimaOS-Terminal zeigt, dass avahi-daemon aktiv ist und während der Fehlerbehebung der lokalen Erkennung mDNS-Schnittstellen registriert
Der serverseitige Avahi-Dienst war aktiv. Damit entfiel eine weitere einfache Erklärung, allerdings war dadurch nicht bewiesen, dass die Ankündigungen das physische LAN korrekt erreichten.

Avahi auf virtuellen Bridges war lediglich eine Hypothese der Community

Eine spätere Antwort bemerkte Avahi-Aktivität auf Docker-/virtuellen Schnittstellen und vermutete, dass der Dienst möglicherweise auf der falschen Bridge statt auf dem Haupt-LAN Ankündigungen sendete. Der Antwortende bat um weitere Journal-Ausgaben.

Der öffentliche Thread endet, bevor diese Hypothese überprüft wurde. Stellen Sie nicht als bestätigte Ursache dar, dass „Avahi an Docker gebunden ist“.

Dass auch Android fehlschlug, änderte die Diagnose

Der Nutzer installierte den Android-Client und berichtete, dass auch dieser den Server nicht automatisch erkennen konnte. Dadurch wurden Erklärungen, die speziell mit dem erweiterten Datenschutz unter iOS, VPN-Einstellungen oder der iOS-Berechtigung für das lokale Netzwerk zusammenhängen, weniger wahrscheinlich.

Als verbleibende Variablen blieben der ZimaOS-Host, der Pfad für die LAN-Erkennung oder eine Wechselwirkung zwischen beiden.

IceWhale bat um Angaben zur Netzwerktopologie und zum Datenschutz

Zima-Giorgio fragte nach VLANs, Firewalls, Protokollfilterung, erweiterten Datenschutz-/VPN-Funktionen unter iOS, der IP-Tracking-Beschränkung und einem Test mit einem anderen Apple-Gerät. Dies war eine offizielle Bitte zur Fehlerbehebung und keine Aussage, dass eine dieser Einstellungen die Ursache des Fehlers war.

Der aktuelle ZimaClient wird kontinuierlich weiterentwickelt

Der aktuelle ZimaClient ist dem Stand vom Oktober 2025 weit voraus und enthält fortlaufende Verbesserungen bei der Zuverlässigkeit von Geräteverbindungen und beim Wechsel zwischen Geräten. Aktualisieren Sie bei einem modernen Fall sowohl ZimaOS als auch ZimaClient, bevor Sie die alten Neuinstallationsversuche wiederholen.

Verwenden Sie die aktuelle Installations- und Verbindungsanleitung für ZimaClient als Ausgangspunkt.

FAQ zur LAN-Erkennung in ZimaClient

Funktionierte die Remote-ID im ursprünglichen Fall?

Ja. Der Nutzer konnte sich innerhalb und außerhalb des Heimnetzwerks über die Remote-ID verbinden.

War der Zugriff auf das lokale Netzwerk unter iOS deaktiviert?

Nein. Der Nutzer veröffentlichte einen Screenshot, der zeigte, dass die Berechtigung aktiviert war.

War Avahi beendet?

Nein. Der Screenshot aus dem ursprünglichen Fall zeigte, dass avahi-daemon lief.

Wurde die endgültige Ursache bestätigt?

Nein. Der öffentliche Thread endete, während noch über zusätzliche Tests zur Netzwerktopologie und zu den Avahi-Schnittstellen diskutiert wurde.