SMB složka vypadá přes VPN zastarale? Zkontrolujte offline soubory

Připojíte VPN, otevřete namapovanou jednotku a ve složce chybí soubor, který server evidentně má. První instinkt je vinit tunel, DNS nebo oprávnění Samby. V mnoha případech je spojení v pořádku a Explorer zobrazuje kešovanou kopii sdílené složky. Offline soubory mohou tuto kopii poskytovat i při zapnuté VPN, protože o tom, zda je zobrazení živé, rozhoduje sdílená složka, ne tunel. Oprava začíná tím, že prokážete, na kterou z nich se díváte.

Mýtus: ikona VPN znamená, že sdílená složka je živá

Ikona VPN hlásí, že k cílovému bodu existuje tunel. Neříká nic o tom, zda je konkrétní sdílená složka SMB dostupná, zda Explorer tuto složku přepnul zpět do režimu online nebo zda selhání synchronizace zanechalo na místě starší kopii. Také neříká, který server vybrala cesta DFS.

Offline soubory uchovávají místní kopii přesměrovaných nebo připnutých sdílených složek aby zůstaly dostupné, když je server nedosažitelný. Když se složka vrátí, klient se má přepnout zpět a synchronizovat. Zásada pomalého připojení může rozhodnout, že spojení je stále příliš pomalé, a ponechat kešované zobrazení, a čekající konflikt může udělat totéž i na rychlém připojení.

Proto symptom působí selektivně: jedna složka je zastaralá, druhá se otevírá správně a třetí se neotevře vůbec. To jsou tři různé stavy a jen první z nich je příběh keše, o kterém tento článek je. Pojmenujte stav, než zvolíte opravu.

Dokažte, který cíl Explorer čte

Začněte přesnou cestou UNC, ne písmenem jednotky. Namapovaná jednotka může ukazovat na jinou sdílenou složku, než si myslíte, a cesta DFS může odkazovat na zcela jiný server. Přečtení mapování ukáže uložený cíl a jeho stav:

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

Otevřete cestu UNC přímo v novém okně Exploreru a porovnejte ji s namapovanou jednotkou. Pokud přímá cesta zobrazuje aktuální soubor a namapovaná jednotka ne, je mapování součástí problému, ne keš.

Poté ověřte, že soubor existuje pro zamýšleného uživatele. Výpis správce na serveru dokazuje existenci, ne že běžný uživatel SMB má stejný přístup, proto to zkontrolujte účtem, který složku skutečně používá. Různé přihlašovací údaje vytvářejí různá zobrazení z důvodů, které s keší nemají nic společného. Existence, přístup a viditelnost jsou tři samostatné kontroly.

Přečtěte stav synchronizace, než cokoli vymažete

Centrum synchronizace, kde je funkce dostupná, hlásí, zda složka pracuje offline, zda poslední synchronizace selhala a zda čekají konflikty. Tyto tři stavy vedou k různým opravám a vymazání keše při čekajícím konfliktu může zničit místní práci.

Než vypnete kešování, odepnete složku nebo smažete offline kopii, hledejte místní změny, které se nedostaly na server. Soubor, který existuje jen v keši, není zastaralé zobrazení; jsou to nesynchronizovaná data a nejprve je třeba je zachovat schváleným postupem. Keš s čekajícími změnami není bezpečné mazat.

Jakmile je místní práce v bezpečí, použijte podporovaný přechod do režimu online a synchronizaci a poté výpis znovu porovnejte. Otevření druhého okna Exploreru nevynutí obnovení, protože obě okna mohou číst stejnou místní keš.

Opravte stav složky místo toho, abyste funkci mazali

Pokud složka zůstává offline kvůli zásadě pomalého připojení, upravte zásadu pro tuto složku nebo síť, místo abyste offline soubory vypínali všem uživatelům. Pokud synchronizace stále selhává, opravte selhání a vyřešte konflikty; funkční synchronizace je to, co znovu aktualizuje kešovanou kopii. Změňte nejmenší zásadu, která složku pokrývá. Globální změna vymění zastaralé zobrazení jednoho uživatele za ztrátu offline přístupu všech.

Pro složky, které by se nikdy neměly kešovat, může server poslat nápovědu pro každou složku. Samba ji zpřístupňuje jako parametr složky a hodnota pro složku, která musí zůstat pouze online, je:

csc policy = disable

reference parametrů Samby definuje povolené hodnoty a jejich význam. Nastavení použijte přes správce složek, který konfiguraci skutečně generuje, zejména na NAS, a pamatujte, že nápověda neopraví data už uložená v keši na klientovi.

Po každé změně zásady ověřte, že se klient znovu připojí a že se očekávaný soubor objeví. Restartovaná služba není důkazem, že čekající místní změna byla nahrána, proto kontrolujte soubor, ne jen stav připojení.

Když příčinou nejsou offline soubory

Pokud je cesta UNC potvrzena online a čerstvý výpis se přesto liší, keš není vysvětlení. Zkontrolujte oprávnění složky a souborového systému, výčet založený na přístupu a server, který odkaz DFS skutečně vybral. Každé z toho může skrýt složku, aniž by byla zapojena místní kopie.

Složka, která se nikdy nepřipojí, potřebuje důkazy o směrování a filtrování služeb, ne kontrolu keše. Blokovaný port 445 přes tunel, název DNS překládaný na špatnou adresu nebo pravidlo firewallu, které povoluje ping, ale ne SMB, to vše vytváří selhání dřív, než keš začne hrát roli.

Test, který obě rodiny odděluje, je jednoduchý: složka, která na serveru existuje, je viditelná správnému uživateli a přesto se neobjeví online, ukazuje na zásadu nebo výčet; složka, která se objeví se starým obsahem, ukazuje na keš. Než změníte nastavení, diagnostikujte rodinu.