Verifiera att fantomresurserna kommer från servern
ZimaCube-ägaren kunde fortfarande se och montera tomma SMB-resurser från två misslyckade försök att konfigurera RAID5. Aktuella resurser i ZimaOS 1.2.2 kunde läggas till och tas bort normalt, men de äldre namnen blev kvar i nätverksresursväljaren.
En Mac som aldrig hade anslutit till ZimaCube visade samma föråldrade namn. Det testet uteslöt en cache som var begränsad till en klient och visade att det föråldrade tillståndet fanns på serversidan.
Upprepa den lågriskkontrollen innan du ändrar servern: jämför listan från en ny klient eller en ren profil med de aktiva resurserna som visas i ZimaOS Filer. Notera vilka poster som är verkliga och vilka som monteras som tomma.
Bygg inte om den fungerande RAID-konfigurationen för att ta bort resursnamn
Teamet uppgav att reparationsprincipen var att undvika att tvinga användare att bygga om eller läsa in RAID-data igen om det inte var nödvändigt. Senare bekräftade teamet att resursproblemet inte skulle påverka befintliga RAID-data.
Det skiljer lagringsintegritet från rensning av resurslistan. Verifiera den aktuella arrayen och de verkliga resurserna först. Om RAID-konfigurationen är felfri och data fortfarande är åtkomliga är fantomnamn inte ett tecken på att arrayen måste återskapas.
Om själva arrayen är degraderad eller saknas ska du avbryta och behandla det som en separat återställningsincident. Blanda inte ihop en lagringsreparation med SMB-rensning, eftersom det då inte längre går att avgöra vilken ändring som påverkade vilket problem.
Teamet bekräftade ett fel i resurshanteringen
En medlem av ZimaOS-teamet bekräftade att fil- och lagringsåtgärder då inte var kopplade till rensning av resurser. En annan användare rapporterade ett relaterat symtom: när en delad mapp bytte namn eller togs bort förblev dess gamla SMB-namn aktivt.
Det ursprungliga problemet började efter att ZimaOS 1.2 inte kunde bevara RAID-konfigurationen efter strömavbrott eller omstarter. Uppdatering till 1.2.1 och 1.2.2 stoppade felet med att RAID-konfigurationen inte bevarades, men de föråldrade resursregistren blev kvar.
ZimaOS 1.2.3 tog inte bort dem. Teamet uppgav att korrigeringen var planerad för 1.2.4 och erbjöd fjärrhjälp dessförinnan, men ämnet innehåller inget senare inlägg som bekräftar att 1.2.4 rensade författarens poster. Bevara den versionsgränsen.
Undvik att redigera genererade Samba-filer manuellt
Författaren hittade föråldrade definitioner i /etc/samba/smb.casa.conf. Redigering, borttagning eller ersättning av filen kvarstod inte efter omstart, och nätverkslistan innehöll ibland fler namn än själva filen.
Det beteendet tyder på att en annan komponent återskapade eller tillhandahöll resursstatusen. Upprepade manuella redigeringar riskerar att skapa avvikelser från ZimaOS-hanteringen utan att ge en bestående lösning.
Återställ eventuella experimentella ändringar, låt den aktiva RAID-konfigurationen vara orörd och använd det stödda gränssnittet, uppdateringsvägen eller processen för fjärrsupport. Återställningen måste valideras från en ny klient efter en omstart, inte bara genom att granska en enda konfigurationsfil.
Eskalerа med en reproducerbar resursinventering
Om en stödd uppdatering inte tar bort fantomposterna ska du samla in ZimaOS-versionen, resurslistan i Filer, klientens resursväljare och namnen som monteras som tomma. Notera att samma lista visas på en ny klient.
Begär åtgärd av resursstatusen utan att godkänna en RAID-ombyggnad, såvida inte lagringsdata oberoende kräver det. Teamet erbjöd fjärrhjälp specifikt för att ta bort spökresurserna före den planerade uppdateringen.
Efter åtgärden ska du starta om en gång, återansluta från både en befintlig och en ny klient och bekräfta att endast aktiva resurser visas och öppnar de förväntade sökvägarna. Det fullständiga testet bevisar att återställningen lyckats.
Vanliga frågor
Är fantomresurser för SMB bara ett cacheproblem i macOS?
Inte i det här fallet. En Mac utan tidigare anslutning till ZimaCube såg samma poster.
Tog ZimaOS 1.2.3 bort de gamla resurserna?
Nej. Författaren rapporterade uttryckligen att 1.2.3 inte löste problemet.
Bekräftade ämnet att ZimaOS 1.2.4 löste felet?
Teamet planerade korrigeringen för 1.2.4, men tråden innehåller ingen slutlig validering från användaren.
