SMB aplankas per VPN atrodo pasenęs? Patikrinkite neprisijungusius failus
Explorer gali rodyti podėlyje saugomą kopiją, kol VPN prijungtas. Palyginkite UNC kelią, sinchronizavimo būseną ir laukiančius pakeitimus prieš išjungdami neprisijungusius failus.
Prisijungiate prie VPN, atidarote priskirtą diską, ir aplanke trūksta failo, kurį serveris akivaizdžiai turi. Pirmas instinktas – kaltinti tunelį, DNS arba Samba leidimus. Daugeliu atvejų ryšys tvarkingas, o Explorer rodo podėlyje saugomą kopiją. Neprisijungę failai gali tiekti tą kopiją net kai VPN įjungtas, nes būtent podėlis, o ne tunelis, sprendžia, ar vaizdas aktualus. Taisymas prasideda įrodžius, į kurią iš jų žiūrite.
Mitas: VPN piktograma reiškia, kad podėlis aktualus
VPN piktograma praneša, kad yra tunelis į galinį tašką. Ji nieko nesako apie tai, ar konkretus SMB podėlis pasiekiamas, ar Explorer grąžino tą podėlį į prisijungimo režimą, ar nepavykusi sinchronizacija paliko senesnę kopiją. Ji taip pat nepasako, kurį serverį pasirinko DFS kelias.
Neprisijungę failai saugo vietinę nukreiptų ar prisegtų podėlių kopiją kad jie liktų prieinami, kai serveris nepasiekiamas. Kai podėlis grįžta, klientas turėtų sugrįžti į prisijungimo režimą ir sinchronizuoti. Lėto ryšio politika gali nuspręsti, kad ryšys vis dar per lėtas, ir išlaikyti podėlyje saugomą vaizdą, o laukiantis konfliktas gali padaryti tą patį net greitame ryšyje.
Todėl simptomas atrodo selektyvus: vienas aplankas pasenęs, kitas atsidaro teisingai, o trečias visai neatsidaro. Tai trys skirtingos būsenos, ir tik pirmoji yra šio straipsnio nagrinėjama podėlio istorija. Įvardykite būseną prieš rinkdamiesi taisymą.
Įrodykite, kurį tikslą skaito Explorer
Pradėkite nuo tikslaus UNC kelio, o ne disko raidės. Priskirtas diskas gali rodyti kitą podėlį nei manote, o DFS kelias gali nurodyti visai kitą serverį. Perskaičius priskyrimą matomas išsaugotas tikslas ir jo būsena:
Get-SmbMapping | Select-Object LocalPath, RemotePath, Status
Get-SmbConnection
net useAtidarykite UNC kelią tiesiogiai naujame Explorer lange ir palyginkite su priskirtu disku. Jei tiesioginis kelias rodo dabartinį failą, o priskirtas diskas – ne, priskyrimas yra problemos dalis, o ne podėlis.
Tada patvirtinkite, kad failas egzistuoja numatytam naudotojui. Administratoriaus sąrašas serveryje įrodo egzistavimą, o ne tai, kad įprastas SMB naudotojas turi tokią pačią prieigą, todėl tikrinkite su paskyra, kuri iš tikrųjų naudoja podėlį. Skirtingi prisijungimo duomenys sukuria skirtingus vaizdus dėl priežasčių, nesusijusių su podėliu. Egzistavimas, prieiga ir matomumas yra trys atskiri patikrinimai.
Perskaitykite sinchronizavimo būseną prieš ką nors ištrindami
Sinchronizavimo centras, kur funkcija prieinama, praneša, ar podėlis veikia neprisijungęs, ar paskutinė sinchronizacija nepavyko ir ar laukia konfliktai. Šios trys būsenos veda prie skirtingų taisymų, o podėlio trynimas laukiant konflikto gali prarasti vietinį darbą.
Ieškokite vietinių pakeitimų, kurie nepasiekė serverio, prieš išjungdami podėlyje saugojimą, atsegdami podėlį ar ištrindami neprisijungusią kopiją. Failas, kuris egzistuoja tik podėlyje, nėra pasenęs vaizdas; tai nesinchronizuoti duomenys, ir juos pirmiausia reikia išsaugoti patvirtintu procesu. Podėlio su laukiančiais pakeitimais trinti nesaugu.
Kai vietinis darbas saugus, naudokite palaikomą perėjimą į prisijungimo režimą ir sinchronizaciją, tada vėl palyginkite sąrašą. Antro Explorer lango atidarymas nepriverčia atnaujinti, nes abu langai gali skaityti tą patį vietinį podėlį.
Taisykite podėlio būseną, o ne trinkite funkciją
Jei podėlis lieka neprisijungęs dėl lėto ryšio politikos, koreguokite politiką tam podėliui ar tinklui, o ne išjunkite neprisijungusius failus visiems naudotojams. Jei sinchronizacija nuolat nepavyksta, ištaisykite gedimą ir išspręskite konfliktus; veikianti sinchronizacija vėl padaro podėlyje saugomą kopiją aktualią. Keiskite mažiausią politiką, apimančią podėlį. Visuotinis pakeitimas iškeičia vieno naudotojo pasenusį vaizdą į visų prarastą neprisijungusią prieigą.
Podėliams, kurie niekada neturėtų būti saugomi podėlyje, serveris gali siųsti užuominą kiekvienam podėliui. Samba pateikia ją kaip podėlio parametrą, o reikšmė podėliui, kuris turi likti tik prisijungus, yra:
csc policy = disableSamba parametrų nuoroda apibrėžia leidžiamas reikšmes ir jų reikšmę. Taikykite nustatymą per podėlių tvarkyklę, kuri iš tikrųjų generuoja konfigūraciją, ypač NAS įrenginyje, ir atminkite, kad užuomina netaiso duomenų, jau saugomų podėlyje kliente.
Po bet kokio politikos pakeitimo patikrinkite, ar klientas vėl prisijungia ir ar atsiranda laukiamas failas. Perkrauta paslauga neįrodo, kad laukiantis vietinis pakeitimas buvo įkeltas, todėl tikrinkite failą, o ne tik ryšio būseną.
Kai priežastis – ne neprisijungę failai
Jei UNC kelias patvirtintas kaip prisijungęs, o naujas sąrašas vis tiek skiriasi, podėlis nėra paaiškinimas. Patikrinkite podėlio ir failų sistemos leidimus, prieiga pagrįstą išvardijimą ir serverį, kurį iš tikrųjų pasirinko DFS nuoroda. Bet kuris iš jų gali paslėpti aplanką be jokios vietinės kopijos.
Podėlis, kuris niekada neprisijungia, reikalauja maršrutizavimo ir paslaugų filtravimo įrodymų, o ne podėlio patikrinimo. Per tunelį užblokuotas 445 prievadas, į neteisingą adresą išsprendžiamas DNS vardas arba ugniasienės taisyklė, leidžianti ping, bet ne SMB, visi sukuria gedimą dar prieš podėliui tampant svarbiam.
Dvi šeimas skiriantis testas paprastas: aplankas, kuris egzistuoja serveryje, matomas tinkamam naudotojui ir vis tiek neatsiranda prisijungus, rodo politiką arba išvardijimą; aplankas, kuris atsiranda su senu turiniu, rodo podėlį. Diagnozuokite šeimą prieš keisdami nustatymą.