Waarom toont een NAS-share oude bestanden nadat de map is vervangen?

Een NAS-share kan oude bestanden tonen wanneer de client of de shareservice nog naar een gecachte mapstatus of het vorige pad verwijst.

Een map op de NAS vervangen garandeert niet dat elke SMB-sessie, toepassing, koppeling, omgekeerde padverwijzing of naamruimte onmiddellijk overschakelt naar de nieuwe mappenstructuur. De server kan het oude pad nog steeds exporteren, de vervanging kan onder een andere koppeling zijn terechtgekomen of de client kan mapmetadata, bestandsinformatie, geopende bestandsdescriptors of een gecachte verwijzing behouden. De veiligste diagnose vergelijkt de weergave van het bestandssysteem, het actieve share-doel en een volledig nieuwe clientsessie voordat een cache-instelling wordt gewijzigd.

Bevestig welke laag de oude mappenstructuur nog toont

Vergelijk de getroffen SMB-client met de NAS-shell, de webbestandsbeheerder van de NAS en een tweede client die de share onlangs niet heeft geopend. Noteer één bestandsnaam die verdwenen zou moeten zijn en één nieuwe bestandsnaam die zichtbaar zou moeten zijn.

Als de NAS-shell en de webbestandsbeheerder ook de oude structuur tonen, ligt het probleem onder SMB: de vervanging is in de verkeerde map uitgevoerd, een verwachte koppeling ontbreekt of een andere dataset bedekt het pad. IBM merkt op dat SMB-wijzigingsmeldingen afhangen van de manier waarop wijzigingen de fileservice bereiken. Eén verouderde client bewijst daarom op zichzelf niet dat de servergegevens oud zijn.

Vernieuw niet steeds dezelfde bestandsbrowser en beschouw dat niet als een nieuwe test. Een zinvolle vergelijking gebruikt een ander clientproces, een andere gebruikerssessie of een directe lokale weergave van het bestandssysteem die niet dezelfde SMB-metadata hergebruikt.

Controleer het actieve share-doel nadat de map is vervangen

Controleer de shareconfiguratie van de server en bepaal naar welk echt bestandssysteemobject het geëxporteerde pad verwijst. Controleer bindkoppelingen, symbolische koppelingen, aankoppelpunten van datasets, volumekoppelingen van containers en of de vervangende map is aangemaakt vóór of nadat een opslagkoppeling actief werd.

Een veelvoorkomende fout ontstaat wanneer de beheerder bestanden vervangt in een niet-aangekoppelde map, waarna de echte opslagkoppeling terugkomt en die vervanging verbergt. De Linux-handleiding voor mounten legt uit dat het aankoppelen de eerdere mapweergave verbergt terwijl het bestandssysteem gekoppeld blijft. Daarom moet het zichtbare pad worden gecontroleerd aan de hand van de actieve koppeltabel.

De NAS-migratiehandleiding van ZimaSpace biedt de bijbehorende verificatiereeks om te bewijzen dat de bedoelde bron- en doelpaden de verwachte gegevens bevatten voordat de oude kopie wordt verwijderd.

Test SMB-caches voor map- en bestandsinformatie

Sluit elke toepassing die de share gebruikt, verbreek de SMB-koppeling en maak een nieuwe sessie. Vergelijk het resultaat met een tweede computer of een nieuwe gebruikerssessie die de map nog niet eerder heeft uitgelezen.

Windows-SMB-clients kunnen mapmetadata en bestandsinformatie gedurende een ingestelde tijd cachen. De richtlijnen van Microsoft voor het afstemmen van bestandsservers leggen uit dat de levensduur van de mapcache bepaalt hoelang metadata in de cache mag blijven wanneer mapleases niet beschikbaar zijn.

Als een nieuwe sessie onmiddellijk de juiste structuur toont terwijl de oude sessie dat niet doet, ontbreken de gegevens niet en is het share-doel waarschijnlijk correct. Verbind de getroffen client opnieuw op een nette manier en onderzoek waarom de sessie de verwachte wijzigingsmelding niet heeft ontvangen of verwerkt voordat je cachewaarden globaal wijzigt.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer geopende bestanden, leases en langlopende toepassingen

Bekijk de actieve SMB-sessies en geopende bestanden op de NAS. Mediamanagers, foto-apps, back-uptools, shellvensters, indexeerders en bestandsbrowsers kunnen mappen of bestanden openhouden lang nadat de zichtbare kopieerbewerking is voltooid.

Sluit eerst de toepassing en verbreek daarna alleen de getroffen SMB-sessie. De SMB-documentatie van NetApp legt uit dat lease-oplocks de clientcachetoestand behouden. Leases op de hele NAS uitschakelen is daarom een veel grotere wijziging dan één verouderde verbinding resetten.

Als de oude structuur pas verdwijnt nadat een specifieke toepassing wordt gesloten, bewaar dat resultaat en test de toepassing opnieuw met de nieuwe map. De corrigerende actie hoort dan bij het gedrag voor opnieuw verbinden, bewaken of vernieuwen van de toepassing, niet bij de opslagpool.

Sluit DFS-verwijzingen en dubbele servernamen uit

Controleer of de client de NAS heeft bereikt via een directe hostnaam, een IP-adres, een DNS-alias, een DFS-naamruimte of een oude servernaam die nu ergens anders naartoe verwijst. Twee paden die er in de bestandsbrowser hetzelfde uitzien, kunnen naar verschillende share-doelen leiden.

DFS-clients cachen naamruimte- en mapverwijzingen gedurende een bepaalde periode. Daardoor kan een client na een wijziging van de naamruimte tijdelijk naar een ouder doel worden gestuurd.

Vergelijk de serveridentiteit, het opgeloste adres, de sharenaam en het uiteindelijke pad van de werkende en de verouderde sessie. Wis niet alle DNS- en DFS-caches voordat je hebt bewezen dat de getroffen client een ander doel bereikt.

Vergelijk een nieuw direct pad met het normale gebruikerspad

Open de share één keer via de normale hostnaam en één keer via het geverifieerde directe serveradres vanuit een nieuwe clientsessie. Gebruik dit alleen als onderscheidende test, niet als permanente vervanging van een beheerde hostnaam.

Als het directe pad de nieuwe structuur toont terwijl de normale naam de oude toont, richt je dan op aliassen, verwijzingen, opgeslagen aanmeldgegevens of een tweede NAS die dezelfde naam gebruikt. Het mount.cifs-padmodel van Debian laat zien waarom het exacte server-/share-doel en het lokale aankoppelpunt moeten worden vergeleken in plaats van te vertrouwen op een bekende weergavenaam.

Vergelijk ook het aantal bestanden en één bestands-hash van het lokale NAS-pad met die van het SMB-pad. Een overeenkomend oud bestand bevestigt een keuze voor het verkeerde pad of de verkeerde cache; een ander bestand met dezelfde naam wijst op een onvolledige vervanging, dubbele mappen of door een toepassing gegenereerde inhoud.

Herstel de kleinste fout en controleer of die na een herstart blijft bestaan

Corrigeer het share-doel wanneer de verkeerde map wordt geëxporteerd, herstel de ontbrekende koppeling wanneer het pad verkeerd wordt afgedekt, verbind de verouderde clientsessie opnieuw wanneer slechts één client is getroffen of werk het DFS-doel bij wanneer de naamruimte nog naar de oude locatie verwijst.

Vermijd het wijzigen van SMB-cachelevensduren, het uitschakelen van leases of het opnieuw aanmaken van de share, tenzij een gecontroleerde test bewijst dat die laag verantwoordelijk is. De weergave van actieve sessies en vergrendelingen van Samba helpt om de getroffen verbinding te controleren voordat je een wijziging voor de hele server toepast.

Het probleem is opgelost wanneer de NAS-shell, de webbestandsbeheerder, een nieuwe SMB-sessie en het normale clientpad na het herstarten van de service en de host allemaal dezelfde mapinhoud tonen. Houd de oude map offline maar intact totdat die controle is geslaagd en geen enkele toepassing er nog naartoe schrijft.