Controleer of de fantoomshares van de server komen
De eigenaar van de ZimaCube kon nog steeds lege SMB-shares van twee mislukte RAID5-configuratiepogingen zien en koppelen. De huidige shares op ZimaOS 1.2.2 konden normaal worden toegevoegd en verwijderd, maar de oudere namen bleven in de netwerksharekiezer staan.
Een Mac die nooit verbinding had gemaakt met de ZimaCube, gaf dezelfde verouderde namen weer. Daarmee werd uitgesloten dat het om een cache op slechts één client ging en werd vastgesteld dat de verouderde status aan de serverzijde stond.
Herhaal deze controle met een laag risico voordat je de server wijzigt: vergelijk de lijst vanaf een nieuwe client of een schoon profiel met de actieve shares die in ZimaOS Files worden weergegeven. Noteer welke vermeldingen echt zijn en welke als leeg worden gekoppeld.
Bouw de werkende RAID niet opnieuw op om sharenamen te verwijderen
Het team gaf aan dat het reparatieprincipe was om gebruikers niet te dwingen RAID-gegevens opnieuw op te bouwen of te laden, tenzij dat onvermijdelijk was. Later bevestigde het dat het shareprobleem geen invloed zou hebben op bestaande RAID-gegevens.
Daarmee worden opslagintegriteit en het opschonen van de sharelijst van elkaar gescheiden. Controleer eerst de huidige array en de echte shares. Als de RAID gezond is en de gegevens toegankelijk blijven, zijn fantoomnamen geen bewijs dat de array opnieuw moet worden aangemaakt.
Als de array zelf gedegradeerd is of ontbreekt, stop dan en behandel dat als een afzonderlijk herstelincident. Combineer een opslagreparatie niet met SMB-opruiming, omdat je anders niet meer kunt vaststellen welke wijziging welk probleem heeft beïnvloed.
Het team bevestigde een bug in sharebeheer
Een teamlid van ZimaOS bevestigde dat bestands- en opslagbewerkingen op dat moment niet gekoppeld waren aan het opruimen van shares. Een andere gebruiker meldde een gerelateerd verschijnsel: het hernoemen of verwijderen van een gedeelde map liet de oude SMB-naam actief.
Het oorspronkelijke probleem begon nadat ZimaOS 1.2 de RAID-configuratie na stroomcycli niet behield. De updates naar 1.2.1 en 1.2.2 stopten het probleem met het bewaren van de RAID-configuratie, maar de verouderde sharerecords bleven bestaan.
ZimaOS 1.2.3 verwijderde ze niet. Het team zei dat de oplossing gepland stond voor 1.2.4 en bood vooraf hulp op afstand aan, maar het onderwerp bevat geen later bericht waarin wordt bevestigd dat 1.2.4 de vermeldingen van de auteur heeft verwijderd. Houd die versiegrens aan.
Bewerk gegenereerde Samba-bestanden niet handmatig
De auteur vond verouderde definities in /etc/samba/smb.casa.conf. Het bewerken, verwijderen of vervangen van dat bestand bleef na een herstart niet behouden, en de netwerklijst bevatte soms meer namen dan het bestand zelf.
Dat gedrag wijst erop dat een andere component de share-status opnieuw genereerde of aanleverde. Herhaalde handmatige bewerkingen kunnen leiden tot afwijkingen van het ZimaOS-beheer zonder een blijvende oplossing op te leveren.
Maak experimentele wijzigingen ongedaan, laat de actieve RAID ongemoeid en gebruik de ondersteunde gebruikersinterface, updateprocedure of het proces voor hulp op afstand. Herstel moet na een herstart vanaf een nieuwe client worden gevalideerd, niet alleen door één configuratiebestand te inspecteren.
Escaleren met een reproduceerbare share-inventaris
Als een ondersteunde update de fantoomvermeldingen niet verwijdert, leg dan de ZimaOS-versie, de sharelijst in Files, de sharekiezer van de client en de namen die leeg worden gekoppeld vast. Noteer dat dezelfde lijst op een nieuwe client verschijnt.
Vraag om herstel van de share-status zonder toestemming te geven voor een RAID-rebuild, tenzij opslaggegevens daar onafhankelijk van vereisen. Het team bood specifiek hulp op afstand aan om de spookshares te verwijderen vóór de geplande update.
Start na het herstel één keer opnieuw op, maak vanaf zowel een bestaande als een nieuwe client opnieuw verbinding en controleer of alleen actieve shares worden weergegeven en de verwachte paden openen. Met die volledige test is het herstel bewezen.
Veelgestelde vragen
Zijn fantoom-SMB-shares alleen een cacheprobleem in macOS?
Niet in dit geval. Een Mac zonder eerdere verbinding met de ZimaCube zag dezelfde vermeldingen.
Heeft ZimaOS 1.2.3 de oude shares verwijderd?
Nee. De auteur meldde expliciet dat 1.2.3 het probleem niet oploste.
Bevestigde het onderwerp dat ZimaOS 1.2.4 de bug heeft opgelost?
Het team plande de oplossing voor 1.2.4, maar de thread bevat geen definitieve gebruikersvalidatie.
