Varför visar en NAS-delning gamla filer efter att mappen har ersatts?
En NAS-delning kan visa gamla filer när klienten eller delningstjänsten fortfarande använder ett cachat katalogtillstånd eller den tidigare sökvägen.
Att ersätta en mapp på NAS-en garanterar inte att varje SMB-session, program, monteringspunkt, omvänd sökväg eller namnrymd omedelbart växlar till det nya katalogträdet. Servern kan fortfarande exportera den gamla sökvägen, ersättningen kan ha hamnat under en annan monteringspunkt eller klienten kan behålla katalogmetadata, filinformation, öppna handtag eller en cachad hänvisning. Den säkraste felsökningen jämför filsystemsvyn, den aktiva delningsmålet och en helt ny klientsession innan någon cacheinställning ändras.
Bekräfta vilket lager som fortfarande visar det gamla katalogträdet
Jämför den berörda SMB-klienten med NAS-skalet, NAS:ens webbaserade filhanterare och en andra klient som inte har öppnat delningen nyligen. Notera ett filnamn som borde ha försvunnit och ett nytt filnamn som borde vara synligt.
Om NAS-skalet och den webbaserade filhanteraren också visar det gamla trädet ligger problemet under SMB: ersättningen gjordes i fel katalog, en förväntad monteringspunkt saknas eller ett annat dataset täcker sökvägen. IBM påpekar att SMB-ändringsaviseringar beror på hur ändringarna når filtjänsten, så en enda inaktuell klient bevisar inte i sig att serverdata är gammal.
Uppdatera inte samma filbläddrare upprepade gånger och betrakta det som ett nytt test. En meningsfull jämförelse använder en annan klientprocess, en annan användarsession eller en direkt lokal filsystemsvy som inte återanvänder samma SMB-metadata.
Verifiera det aktiva delningsmålet efter att mappen har ersatts
Granska serverns delningskonfiguration och fastställ den exporterade sökvägen till det faktiska filsystemobjektet. Kontrollera bindmonteringar, symboliska länkar, datasetens monteringspunkter, mappningar av containervolym och om ersättningsmappen skapades före eller efter att en lagringsmontering blev aktiv.
Ett vanligt fel uppstår när administratören ersätter filer under en omonterad katalog, varefter den riktiga lagringsmonteringen återkommer och döljer ersättningen. Linux-manualen för montering förklarar att montering döljer den tidigare katalogvyn medan filsystemet fortfarande är anslutet. Därför måste den synliga sökvägen kontrolleras mot den aktiva monteringstabellen.
ZimaSpaces guide för NAS-datamigrering innehåller den kompletterande kontrollsekvensen för att bevisa att de avsedda käll- och målsökvägarna innehåller förväntade data innan den gamla kopian tas bort.
Testa SMB-cache för katalog- och filinformation
Stäng alla program som använder delningen, koppla från SMB-mappningen och upprätta en ny session. Jämför resultatet med en annan dator eller en ny användarsession som inte tidigare har läst in katalogen.
Windows SMB-klienter kan cacha katalogmetadata och filinformation under en konfigurerad tidsperiod. Microsofts vägledning för finjustering av filservrar förklarar att katalogcachelivslängden styr hur länge metadata kan förbli cachad när kataloglån inte är tillgängliga.
Om en ny session omedelbart visar rätt träd medan den gamla sessionen inte gör det, saknas inte data och delningsmålet är sannolikt korrekt. Anslut den berörda klienten på nytt på ett ordnat sätt och undersök varför dess session inte tog emot eller följde den förväntade ändringsaviseringen innan cachevärden ändras globalt.
Kontrollera öppna handtag, lån och långlivade program
Lista aktiva SMB-sessioner och öppna filer på NAS-en. Mediehanterare, fotoappar, säkerhetskopieringsverktyg, skal fönster, indexerare och filbläddrare kan hålla kataloger eller filer öppna långt efter att den synliga kopieringen är klar.
Stäng programmet först och koppla sedan från endast den berörda SMB-sessionen. NetApps SMB-dokumentation förklarar att lease-oplocks bevarar klientens cachningstillstånd, så att inaktivera lån på hela NAS-en är en betydligt större ändring än att återställa en enskild inaktuell anslutning.
Om det gamla trädet försvinner först när ett visst program stängs, bevara det resultatet och testa programmet igen med den nya mappen. Åtgärden hör hemma i programmets återanslutnings-, bevaknings- eller uppdateringsbeteende, inte i lagringspoolen.
Uteslut DFS-hänvisningar och dubbletter av servernamn
Kontrollera om klienten nådde NAS-en via ett direkt värdnamn, en IP-adress, ett DNS-alias, en DFS-namnrymd eller ett gammalt servernamn som nu pekar någon annanstans. Två sökvägar som ser likadana ut i filbläddraren kan leda till olika delningsmål.
DFS-klienter cachar namnrymds- och mapphänvisningar under en angiven tidsperiod. DFS-klienter kan också behålla namnrymds- och mapphänvisningar under en period, vilket tillfälligt kan skicka en klient till ett äldre mål efter en ändring av namnrymden.
Jämför serveridentitet, upplöst adress, delningsnamn och slutlig sökväg för den fungerande och den inaktuella sessionen. Töm inte alla DNS- och DFS-cachar förrän du har bevisat att den berörda klienten når ett annat mål.
Jämför en ny direkt sökväg med den normala användarsökvägen
Öppna delningen en gång med det normala värdnamnet och en gång med den verifierade direkta serveradressen från en ren klientsession. Använd detta endast för att skilja mellan olika orsaker, inte som en permanent ersättning för ett hanterat värdnamn.
Om den direkta sökvägen visar det nya trädet medan det normala namnet visar det gamla, bör du fokusera på alias, hänvisningar, sparade inloggningsuppgifter eller en annan NAS som använder samma namn. Debians mount.cifs-sökvägsmodell visar varför det exakta server-/delningsmålet och den lokala monteringspunkten måste jämföras i stället för att förlita sig på ett välbekant visningsnamn.
Jämför också filantalet och en filhash från den lokala NAS-sökvägen och SMB-sökvägen. En matchande gammal fil bekräftar att sökväg eller cache har valts fel; en annan fil med samma namn pekar på ofullständig ersättning, dubbla mappar eller programgenererat innehåll.
Åtgärda det minsta felet och verifiera att det kvarstår efter omstart
Korrigera delningsmålet när det exporterar fel mapp, återställ den saknade monteringen när sökvägen täcks felaktigt, anslut den inaktuella klientsessionen på nytt när endast en klient påverkas eller uppdatera DFS-målet när namnrymden fortfarande hänvisar till den gamla platsen.
Undvik att ändra SMB-cachelivslängder, inaktivera lån eller återskapa delningen om inte ett kontrollerat test visar att det lagret är ansvarigt. Sambas vy över aktiva sessioner och lås gör det möjligt att kontrollera den berörda anslutningen innan en ändring som gäller hela servern tillämpas.
Problemet är löst när NAS-skalet, den webbaserade filhanteraren, den nya SMB-sessionen och den normala klientsökvägen alla visar samma mappinnehåll efter omstart av tjänsten och värddatorn. Håll den gamla mappen frånkopplad men intakt tills verifieringen har godkänts och inget program längre skriver till den.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
