Csatlakozik a VPN-hez, megnyitja a leképezett meghajtót, és a mappából hiányzik egy fájl, amely nyilvánvalóan ott van a kiszolgálón. Az első ösztön a tunel, a DNS vagy a Samba-engedélyek hibáztatása. Sok esetben a kapcsolat rendben van, és az Explorer a megosztás gyorsítótárazott másolatát mutatja. Az offline fájlok akkor is kiszolgálhatják ezt a másolatot, amikor a VPN be van kapcsolva, mert a megosztás, nem a tunel dönti el, hogy a nézet naprakész-e. A javítás azzal kezdődik, hogy bizonyítja, melyiket nézi.

A mítosz: a VPN-ikon azt jelenti, hogy a megosztás naprakész

A VPN-ikon azt jelzi, hogy létezik tunel a végponthoz. Semmit nem mond arról, hogy egy adott SMB-megosztás elérhető-e, hogy az Explorer visszaállította-e azt a megosztást online módba, vagy hogy egy sikertelen szinkronizálás régebbi másolatot hagyott-e a helyén. Arról sem tájékoztat, melyik kiszolgálót választotta egy DFS-útvonal.

Az offline fájlok helyi másolatot tartanak az átirányított vagy rögzített megosztásokról hogy elérhetők maradjanak, amikor a kiszolgáló nem érhető el. Amikor a megosztás visszatér, a kliensnek vissza kell állnia online módba és szinkronizálnia kell. A lassú kapcsolat szabályzata úgy dönthet, hogy a kapcsolat még mindig túl lassú, és megtartja a gyorsítótárazott nézetet, és egy függő ütközés ugyanezt teheti gyors kapcsolat esetén is.

Ezért tűnik szelektívnek a tünet: az egyik mappa elavult, a másik helyesen nyílik meg, a harmadik pedig egyáltalán nem nyílik meg. Ez három különböző állapot, és csak az első az a gyorsítótár-történet, amelyről ez a cikk szól. Nevezze meg az állapotot, mielőtt javítást választ.

Bizonyítsa, melyik célpontot olvassa az Explorer

Kezdje a pontos UNC-útvonallal a meghajtóbetű jel helyett. Egy leképezett meghajtó más megosztásra mutathat, mint gondolja, és egy DFS-útvonal teljesen más kiszolgálóra hivatkozhat. A leképezés kiolvasása megmutatja a mentett célpontot és annak állapotát:

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

Nyissa meg az UNC-útvonalat közvetlenül egy új Explorer-ablakban, és hasonlítsa össze a leképezett meghajtóval. Ha a közvetlen útvonal mutatja az aktuális fájlt, a leképezett meghajtó pedig nem, akkor a leképezés a probléma része, nem a gyorsítótár.

Ezután erősítse meg, hogy a fájl létezik a szánt felhasználó számára. A rendszergazdai lista a kiszolgálón a létezést bizonyítja, nem azt, hogy a szokásos SMB-felhasználó ugyanolyan hozzáféréssel rendelkezik, ezért ellenőrizze azzal a fiókkal, amely valóban használja a megosztást. A különböző hitelesítő adatok különböző nézeteket eredményeznek olyan okokból, amelyeknek semmi közük a gyorsítótárazáshoz. A létezés, a hozzáférés és a láthatóság három külön ellenőrzés.

Olvassa ki a szinkronizálás állapotát, mielőtt bármit törölne

A Szinkronizálási központ, ahol a funkció elérhető, jelzi, hogy a megosztás offline módban működik-e, hogy a legutóbbi szinkronizálás meghiúsult-e, és hogy ütközések várnak-e. Ez a három állapot különböző javításokhoz vezet, és a gyorsítótár törlése függő ütközés esetén helyi munkát veszíthet el.

Keressen olyan helyi módosításokat, amelyek nem értek el a kiszolgálóra, mielőtt letiltja a gyorsítótárazást, leoldja a megosztást vagy törli az offline másolatot. Egy fájl, amely csak a gyorsítótárban létezik, nem elavult nézet; szinkronizálatlan adat, és először a jóváhagyott folyamaton keresztül kell megőrizni. A függő módosításokat tartalmazó gyorsítótárat nem biztonságos törölni.

Ha a helyi munka biztonságban van, használja a támogatott online átállást és szinkronizálást, majd hasonlítsa össze újra a listát. Egy második Explorer-ablak megnyitása nem kényszerít frissítést, mert mindkét ablak ugyanazt a helyi gyorsítótárat olvashatja.

Javítsa a megosztás állapotát a funkció törlése helyett

Ha a megosztás a lassú kapcsolat szabályzata miatt marad offline, módosítsa a szabályzatot arra a megosztásra vagy hálózatra, ahelyett hogy minden felhasználónál kikapcsolná az offline fájlokat. Ha a szinkronizálás folyamatosan meghiúsul, javítsa a hibát és oldja fel az ütközéseket; egy működő szinkronizálás teszi ismét naprakésszé a gyorsítótárazott másolatot. A legkisebb szabályzatot módosítsa, amely lefedi a megosztást. A globális változtatás egy felhasználó elavult nézetét mindenki elveszett offline hozzáférésére cseréli.

Azoknál a megosztásoknál, amelyeket soha nem szabad gyorsítótárazni, a kiszolgáló megosztásonkénti tippet küldhet. A Samba megosztási paraméterként teszi elérhetővé, és a csak online maradó megosztás értéke:

csc policy = disable

Samba-paraméterreferencia határozza meg az engedélyezett értékeket és jelentésüket. A beállítást a megosztáskezelőn keresztül alkalmazza, amely valóban előállítja a konfigurációt, különösen NAS-on, és ne feledje, hogy a tipp nem javítja a kliensen már gyorsítótárazott adatokat.

Minden szabályzatváltozás után ellenőrizze, hogy a kliens újra csatlakozik, és megjelenik a várt fájl. Az újraindított szolgáltatás nem bizonyítja, hogy egy függő helyi módosítás feltöltődött, ezért a fájlt ellenőrizze, ne csak a kapcsolat állapotát.

Amikor nem az offline fájlok az ok

Ha az UNC-útvonal online állapota megerősített, és egy friss lista mégis eltér, a gyorsítótár nem magyarázat. Ellenőrizze a megosztás és a fájlrendszer engedélyeit, a hozzáférés-alapú számbavételt és azt a kiszolgálót, amelyet egy DFS-hivatkozás valóban kiválasztott. Ezek bármelyike elrejthet egy mappát helyi másolat nélkül.

Egy soha nem csatlakozó megosztás útvonalválasztási és szolgáltatásszűrési bizonyítékot igényel, nem gyorsítótár-ellenőrzést. A tunelen át blokkolt 445-es port, egy rossz címre feloldódó DNS-név vagy egy tűzfalszabály, amely pinget enged, de SMB-t nem, mindegyik hibát okoz, mielőtt a gyorsítótár számítana.

A két családot elválasztó teszt egyszerű: egy mappa, amely létezik a kiszolgálón, látható a megfelelő felhasználónak, és mégsem jelenik meg online, szabályzatra vagy számbavételre utal; egy mappa, amely régi tartalommal jelenik meg, a gyorsítótárra utal. A beállítás módosítása előtt diagnosztizálja a családot.

Kapcsolódó cikkek