SMB-map sjocht ferâldere út oer VPN? Kontrolearje Offline-bestannen

Jo ferbine de VPN, iepenje it taheakke stasjon, en yn 'e map mist in bestân dat de tsjinner dúdlik hat. De earste ympuls is de tunnel, de DNS of Samba-rjochten de skuld te jaan. Yn in protte gefallen is de ferbining goed en lit Verkenner in yn 't cache bewarre kopy fan it diel sjen. Offline-bestannen kinne dy kopy leverje sels wylst de VPN oan is, want it diel, net de tunnel, beslút oft de werjefte libben is. De reparaasje begjint mei te bewizen hokker fan de beide jo sjogge.

De myte: in VPN-ikoan betsjut dat it diel libben is

It VPN-ikoan meldt dat der in tunnel nei it einpunt bestiet. It seit neat oer oft in beskaat SMB-diel berikber is, oft Verkenner dat diel werom set hat nei online-modus of oft in mislearre syngronisaasje in âldere kopy stean litten hat. It fertelt jo ek net hokker tsjinner in DFS-paad keazen hat.

Offline-bestannen hâlde in pleatslike kopy fan omstjoerde of fêstsette dielen sadat se beskikber bliuwe as de tsjinner net berikber is. As it diel weromkomt, heart de klant werom te gean nei online en te syngronisearjen. In belied foar stadige ferbining kin beslute dat de ferbining noch te stadich is en de cache-werjefte hâlde, en in wachtjend konflikt kin itselde dwaan sels op in flugge ferbining.

Dêrom liket it symptoom selektiv: ien map is ferâldere, in oare iepenet goed en in tredde iepenet hielendal net. Dat binne trije ferskillende steaten, en allinnich de earste is it cache-ferhaal dêr't dit artikel oer giet. Neam de steat foardat jo in reparaasje kieze.

Bewiis hokker doel Verkenner lêst

Begjin mei it krekte UNC-paad ynstee fan de stasjonsletter. In taheakke stasjon kin nei in oar diel wize as dat jo tinke, en in DFS-paad kin nei in hiel oare tsjinner ferwize. It lêzen fan 'e taheakking lit it bewarre doel en syn steat sjen:

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

Iepenje it UNC-paad direkt yn in nij Verkenner-finster en ferlykje it mei it taheakke stasjon. As it direkte paad it aktuele bestân lit sjen en it taheakke stasjon net, is de taheakking diel fan it probleem, net de cache.

Befêstigje dêrnei dat it bestân bestiet foar de bedoelde brûker. In behearderslist op 'e tsjinner bewizet it bestean, net dat de gewoane SMB-brûker deselde tagong hat, dus kontrolearje mei it akkount dat it diel echt brûkt. Ferskillende oanmeldgegevens leverje ferskillende werjeften om redenen dy't neat mei cache te krijen hawwe. Bestean, tagong en sichtberens binne trije aparte kontrôles.

Lês de syngronisaasjesteat foardat jo eat wiskje

It Syngronisaasjesintrum, wêr't de funksje beskikber is, meldt oft it diel offline wurket, oft de lêste syngronisaasje mislearre is en oft konflikten wachtsje. Dy trije steaten liede ta ferskillende reparaasjes, en it wiskjen fan 'e cache wylst in konflikt wachtet kin pleatslik wurk ferlieze.

Sykje nei pleatslike wizigings dy't de tsjinner net berikt hawwe foardat jo caching útskeakelje, it diel losmeitsje of de offline-kopy wiskje. In bestân dat allinnich yn 'e cache bestiet is gjin ferâldere werjefte; it binne net-syngronisearre gegevens, en dy moatte earst fia it goedkarde proses bewarre wurde. In cache mei wachtjende wizigings is net feilich om te wiskjen.

As it pleatslike wurk feilich is, brûk de stipe oergong nei online en de syngronisaasje, en ferlykje dêrnei de list wer. It iepenjen fan in twadde Verkenner-finster twingt gjin ferfarsking, want beide finsters kinne deselde pleatslike cache lêze.

Reparearje de steat fan it diel ynstee fan 'e funksje te wiskjen

As it diel offline bliuwt troch in belied foar stadige ferbining, pas it belied oan foar dat diel of netwurk ynstee fan Offline-bestannen foar alle brûkers út te skeakeljen. As syngronisaasje oanhâldend mislearret, reparearje de flater en los de konflikten op; in wurkjende syngronisaasje is wat de cache-kopy wer aktueel makket. Feroarje it lytste belied dat it diel beslacht. In globale feroaring ruilet de ferâldere werjefte fan ien brûker foar it ferlerne offline-tagong fan allegear.

Foar dielen dy't nea yn 'e cache moatte, kin de tsjinner in oanwizing per diel stjoere. Samba eksposearret it as dielparameter, en de wearde foar in diel dat allinnich online bliuwe moat is:

csc policy = disable

Samba-parameterreferinsje definiearret de tastiene wearden en har betsjutting. Pas de ynstelling ta fia de dielbehearder dy't de konfiguraasje echt generearret, benammen op in NAS, en tink deroan dat de oanwizing gegevens dy't al op in klant yn 'e cache steane net reparearret.

Nei elke beliedswiziging, kontrolearje dat de klant wer ferbynt en dat it ferwachte bestân ferskynt. In werstarte tsjinst is gjin bewiis dat in wachtjende pleatslike wiziging opladen is, dus kontrolearje it bestân, net allinnich de steat fan 'e ferbining.

As de oarsaak net Offline-bestannen is

As it UNC-paad as online befêstige is en in nije list noch altyd ferskilt, is de cache net de ferklearring. Kontrolearje de rjochten fan it diel en it bestânssysteem, de tagong-basearre opsomming en de tsjinner dy't in DFS-ferwizing echt keazen hat. Elk dêrfan kin in map ferbergje sûnder dat in pleatslike kopy belutsen is.

In diel dat nea ferbynt hat bewiis fan routing en tsjinstfiltering nedich, gjin cache-kontrôle. Poarte 445 blokkearre oer de tunnel, in DNS-namme dy't nei it ferkearde adres oplost of in fjoermuorre-regel dy't ping tastean mar gjin SMB, produsearje allegear in flater foardat de cache wat útmakket.

De test dy't de twa famyljes skiedt is ienfâldich: in map dy't op 'e tsjinner bestiet, sichtber is foar de juste brûker en dochs net online ferskynt wiist op belied of opsomming; in map dy't mei âlde ynhâld ferskynt wiist op de cache. Diagnostisearje de famylje foardat jo in ynstelling feroarje.