Community-Lösung

Phantom-SMB-Freigaben auf dem ZimaCube: Bestätigter Fehler und sichere Abgrenzung

Obsolete SMB shares remained discoverable after early RAID attempts; the ZimaOS team confirmed a share-cleanup bug and said remediation should not require rebuilding existing RAID data.

Überprüfen, ob die Phantom-Freigaben vom Server stammen

Der Besitzer des ZimaCube konnte weiterhin leere SMB-Freigaben aus zwei fehlgeschlagenen RAID5-Einrichtungsversuchen sehen und einbinden. Aktuelle Freigaben ließen sich unter ZimaOS 1.2.2 normal hinzufügen und entfernen, aber die älteren Namen blieben in der Auswahl der Netzwerkfreigaben erhalten.

Ein Mac, der noch nie mit dem ZimaCube verbunden war, zeigte dieselben veralteten Namen an. Damit war ein auf einen einzelnen Client beschränkter Cache ausgeschlossen und der veraltete Zustand auf der Serverseite verortet.

Wiederholen Sie diese risikoarme Prüfung, bevor Sie den Server ändern: Vergleichen Sie die Liste auf einem neuen Client oder in einem sauberen Profil mit den aktiven Freigaben, die in den ZimaOS-Dateien angezeigt werden. Notieren Sie, welche Einträge tatsächlich vorhanden sind und welche als leer eingebunden werden.

SMB-Freigabeauswahl mit veralteten ZimaCube-Freigabenamen
Das Problem war die vom Server angekündigte Freigabenliste, nicht der lokale Verlauf eines einzelnen Macs.

Funktionierendes RAID nicht neu aufbauen, um Freigabenamen zu entfernen

Das Team erklärte, sein Reparaturprinzip bestehe darin, Nutzer nicht zu einem Neuaufbau oder erneuten Laden von RAID-Daten zu zwingen, sofern dies nicht unvermeidbar sei. Später bestätigte es, dass das Freigabenproblem keine bestehenden RAID-Daten beeinträchtigen würde.

Damit werden Speicherintegrität und die Bereinigung der Freigabenliste voneinander getrennt. Überprüfen Sie zuerst das aktuelle Array und die tatsächlich vorhandenen Freigaben. Wenn das RAID fehlerfrei ist und die Daten weiterhin zugänglich sind, sind Phantomnamen kein Hinweis darauf, dass das Array neu erstellt werden muss.

Wenn das Array selbst beeinträchtigt ist oder fehlt, halten Sie an und behandeln Sie dies als separaten Wiederherstellungsvorfall. Verbinden Sie eine Speicherreparatur nicht mit der SMB-Bereinigung, da sonst nicht mehr festgestellt werden kann, welche Änderung welches Problem beeinflusst hat.

SMB-Auswahl mit echten und Phantom-Freigaben des ZimaCube
Der Autor identifizierte in dieser Ansicht nur Video, Music und SleepData als echte Freigaben.

Das Team bestätigte einen Fehler in der Freigabenverwaltung

Ein Mitglied des ZimaOS-Teams bestätigte, dass Datei- und Speicheroperationen damals nicht mit der Bereinigung von Freigaben verknüpft waren. Ein anderer Nutzer meldete ein verwandtes Symptom: Beim Umbenennen oder Löschen eines freigegebenen Ordners blieb dessen alter SMB-Name aktiv.

Das ursprüngliche Problem begann, nachdem ZimaOS 1.2 die RAID-Konfiguration über Neustarts hinweg nicht beibehielt. Die Aktualisierung auf 1.2.1 und 1.2.2 beendete den Fehler bei der RAID-Persistenz, aber die veralteten Freigabendatensätze blieben bestehen.

ZimaOS 1.2.3 entfernte sie nicht. Das Team erklärte, die Behebung sei für 1.2.4 geplant, und bot vorherige Fernunterstützung an. Der Beitrag enthält jedoch keinen späteren Eintrag, der bestätigt, dass 1.2.4 die Einträge des Autors gelöscht hat. Behalten Sie diese Versionsgrenze bei.

Generierte Samba-Dateien nicht manuell bearbeiten

Der Autor fand veraltete Definitionen in /etc/samba/smb.casa.conf. Änderungen, das Löschen oder Ersetzen dieser Datei blieben nach einem Neustart nicht erhalten, und die Netzwerkliste enthielt manchmal mehr Namen als die Datei selbst.

Dieses Verhalten deutet darauf hin, dass eine andere Komponente den Freigabenstatus neu erzeugte oder bereitstellte. Wiederholte manuelle Änderungen bergen das Risiko, dass der Zustand von der ZimaOS-Verwaltung abweicht, ohne eine dauerhafte Reparatur zu bewirken.

Machen Sie experimentelle Änderungen rückgängig, lassen Sie das aktive RAID unangetastet und verwenden Sie die unterstützte Benutzeroberfläche, den vorgesehenen Aktualisierungspfad oder den Fernsupport. Die Wiederherstellung muss nach einem Neustart von einem neuen Client aus überprüft werden, nicht nur durch die Kontrolle einer einzelnen Konfigurationsdatei.

Nach Konfigurationsänderungen verbleibende ZimaCube-SMB-Freigabenliste
Die manuellen Änderungen an der Datei stimmten nicht mit dem vollständigen, vom Server angekündigten Zustand überein.

Mit einer reproduzierbaren Freigabenübersicht eskalieren

Wenn ein unterstütztes Update die Phantom-Einträge nicht entfernt, erfassen Sie die ZimaOS-Version, die Freigabenliste in den Dateien, die Freigabeauswahl des Clients und die Namen, die leer eingebunden werden. Vermerken Sie, dass dieselbe Liste auf einem neuen Client erscheint.

Fordern Sie eine Bereinigung des Freigabenstatus an, ohne einen RAID-Neuaufbau zu genehmigen, sofern nicht unabhängig davon Hinweise auf ein Speicherproblem vorliegen. Das Team bot ausdrücklich Fernunterstützung an, um die Geisterfreigaben vor dem geplanten Update zu entfernen.

Starten Sie das System nach der Bereinigung einmal neu, verbinden Sie sich erneut von einem vorhandenen und einem neuen Client und bestätigen Sie, dass nur aktive Freigaben angezeigt werden und die erwarteten Pfade geöffnet werden. Dieser vollständige Test bestätigt die Wiederherstellung.

FAQ

Sind Phantom-SMB-Freigaben nur ein macOS-Cache-Problem?

In diesem Fall nicht. Ein Mac ohne vorherige Verbindung zum ZimaCube zeigte dieselben Einträge.

Hat ZimaOS 1.2.3 die alten Freigaben entfernt?

Nein. Der Autor berichtete ausdrücklich, dass 1.2.3 das Problem nicht behoben hatte.

Bestätigte der Beitrag, dass ZimaOS 1.2.4 den Fehler behoben hat?

Das Team plante die Behebung für 1.2.4, aber der Beitrag enthält keine abschließende Bestätigung durch einen Nutzer.