Folderul SMB pare învechit prin VPN? Verificați fișierele offline

Vă conectați la VPN, deschideți unitatea mapată și în folder lipsește un fișier pe care serverul îl are clar. Primul instinct este să dați vina pe tunel, pe DNS sau pe permisiunile Samba. În multe cazuri conexiunea este în regulă, iar Explorer afișează o copie memorată în cache a partajului. Fișierele offline pot servi acea copie chiar și cu VPN-ul pornit, pentru că partajul, nu tunelul, decide dacă vizualizarea este la zi. Reparația începe prin a dovedi pe care dintre ele o priviți.

Mitul: o pictogramă VPN înseamnă că partajul este la zi

Pictograma VPN raportează că există un tunel către punctul final. Nu spune nimic despre faptul dacă un anumit partaj SMB este accesibil, dacă Explorer a readus acel partaj în modul online sau dacă o sincronizare eșuată a lăsat o copie mai veche. Nu vă spune nici ce server a ales o cale DFS.

Fișierele offline păstrează o copie locală a partajelor redirecționate sau fixate pentru ca acestea să rămână disponibile când serverul nu este accesibil. Când partajul revine, clientul ar trebui să revină online și să sincronizeze. O politică de legătură lentă poate decide că conexiunea este încă prea lentă și poate păstra vizualizarea din cache, iar un conflict în așteptare poate face același lucru chiar și pe o legătură rapidă.

De aceea simptomul pare selectiv: un folder este învechit, altul se deschide corect, iar al treilea nu se deschide deloc. Sunt trei stări diferite, și doar prima este povestea cache-ului despre care este acest articol. Numiți starea înainte de a alege o reparație.

Dovediți ce țintă citește Explorer

Începeți cu calea UNC exactă, nu cu litera unității. O unitate mapată poate indica un alt partaj decât cel la care vă gândiți, iar o cale DFS poate face referire la cu totul alt server. Citirea mapării arată ținta salvată și starea acesteia:

Get-SmbMapping | Select-Object LocalPath, RemotePath, Status
Get-SmbConnection
net use

Deschideți calea UNC direct într-o fereastră nouă Explorer și comparați-o cu unitatea mapată. Dacă calea directă arată fișierul curent, iar unitatea mapată nu, maparea face parte din problemă, nu cache-ul.

Apoi confirmați că fișierul există pentru utilizatorul prevăzut. O listare de administrator pe server dovedește existența, nu că utilizatorul SMB obișnuit are același acces, așa că verificați cu contul care folosește efectiv partajul. Acreditări diferite produc vizualizări diferite din motive care nu au legătură cu cache-ul. Existența, accesul și vizibilitatea sunt trei verificări separate.

Citiți starea de sincronizare înainte de a șterge ceva

Centrul de sincronizare, acolo unde funcția este disponibilă, raportează dacă partajul lucrează offline, dacă ultima sincronizare a eșuat și dacă așteaptă conflicte. Aceste trei stări duc la reparații diferite, iar ștergerea cache-ului în timp ce un conflict este în așteptare poate pierde munca locală.

Căutați modificări locale care nu au ajuns la server înainte de a dezactiva cache-ul, a dezvăța partajul sau a șterge copia offline. Un fișier care există doar în cache nu este o vizualizare învechită; sunt date nesincronizate, iar acestea trebuie păstrate mai întâi prin procesul aprobat. Un cache cu modificări în așteptare nu este sigur de șters.

După ce munca locală este în siguranță, folosiți tranziția online și sincronizarea acceptate, apoi comparați din nou listarea. Deschiderea unei a doua ferestre Explorer nu forțează o reîmprospătare, pentru că ambele ferestre pot citi același cache local.

Reparați starea partajului în loc să ștergeți funcția

Dacă partajul rămâne offline din cauza unei politici de legătură lentă, ajustați politica pentru acel partaj sau acea rețea în loc să dezactivați fișierele offline pentru toți utilizatorii. Dacă sincronizarea eșuează în continuare, reparați eroarea și rezolvați conflictele; o sincronizare funcțională este ceea ce face din nou copia din cache actuală. Schimbați cea mai mică politică ce acoperă partajul. O schimbare globală schimbă vizualizarea învechită a unui utilizator pe pierderea accesului offline al tuturor.

Pentru partajele care nu ar trebui memorate niciodată în cache, serverul poate trimite un indiciu pentru fiecare partaj. Samba îl expune ca parametru al partajului, iar valoarea pentru un partaj care trebuie să rămână doar online este:

csc policy = disable

referința parametrilor Samba definește valorile permise și semnificația lor. Aplicați setarea prin managerul de partaje care generează efectiv configurația, mai ales pe un NAS, și rețineți că indiciul nu repară datele deja memorate în cache pe un client.

După orice modificare de politică, verificați că clientul se reconectează și că fișierul așteptat apare. Un serviciu repornit nu este dovada că o modificare locală în așteptare a fost încărcată, așa că verificați fișierul, nu doar starea conexiunii.

Când cauza nu sunt fișierele offline

Dacă calea UNC este confirmată online și o listare nouă diferă în continuare, cache-ul nu este explicația. Verificați permisiunile partajului și ale sistemului de fișiere, enumerarea bazată pe acces și serverul pe care o referință DFS l-a ales efectiv. Oricare dintre acestea poate ascunde un folder fără nicio copie locală.

Un partaj care nu se conectează niciodată are nevoie de dovezi de rutare și filtrare a serviciilor, nu de o verificare a cache-ului. Portul 445 blocat prin tunel, un nume DNS care se rezolvă la adresa greșită sau o regulă de firewall care permite ping, dar nu SMB, produc toate o eroare înainte ca cache-ul să conteze.

Testul care separă cele două familii este simplu: un folder care există pe server, este vizibil pentru utilizatorul corect și tot nu apare online indică politica sau enumerarea; un folder care apare cu conținut vechi indică cache-ul. Diagnosticați familia înainte de a schimba o setare.