SMB share pagkatapos ng pagbagsak ng VPN: checklist sa pagbawi

Nag-hang ang iyong pag-save, bumabagsak ang tunel, at makalipas ang tatlumpung segundo konektado na muli ang VPN habang umiikot ang bintana ng Finder sa walang laman na share. Mukhang dapat gumana ang lahat. Nasa taas ang tunel, nasa taas ang network, at wala ang volume. Sundan ito nang sunod-sunod, dahil ang muling pagkonekta habang iniisip pa ng aplikasyon na may hawak itong bukas na handle ang paraan kung paanong ang hindi tiyak na pagsulat ay nagiging nawalang pagsulat.

Magsimula sa pagtigil ng trabaho sa share sa halip na muling ikonekta ito. Mukha itong pasibo at ito ang hakbang na nagpoprotekta sa iyong data.

Itigil ang pagsulat bago muling kumonekta

Isara ang lahat ng aktibong sinusubukang magsulat, at i-save ang kaya mo sa lokal na lokasyon sa pamamagitan ng sariling landas ng pag-save o pagbawi ng aplikasyon. Huwag magsimula ng malaking kopya, huwag hayaang magretry nang walang hanggan ang isang sync client, at huwag tanggapin ang prompt na nag-aalok na palitan ang kopya sa server ng iyong lokal. Ang ikatlong tagubilin ang nagkakahalaga ng data, dahil ang pag-save na nag-time out ay hindi kumpirmado at hindi rin tiyak na wala, at ang pag-overwrite sa file sa server ay nag-aalis ng tanging ebidensya ng tunay na nangyari.

Kung nagpapakita ang aplikasyon ng dalawang bersyon ng parehong dokumento, iwanan muna ang dalawa sa kani-kanilang lugar. Ang pagpili ng panalo batay sa pangalan ng file o timestamp ay haka-haka na nakasuot ng desisyon.

Ibalik ang landas, pagkatapos patunayan ito

Muling ikonekta ang nilalayong VPN at tapusin ang authentication nito, pagkatapos tiyakin na nalulutas ang pangalan ng file server at tumutugon ang serbisyo ng SMB sa pamamagitan ng tunel. Ang katayuang konektado ay naglalarawan lamang ng tunel, kaya ituring itong simula ng pagsusuri at hindi ang wakas.

1. Tiyakin ang resolusyon ng pangalan at maabot ng file server sa pamamagitan ng tunel.

2. Bigyan ng isang minuto ang umiiral na mount bago gumawa ng iba; ang ikalawang volume na may parehong label ay mas mahirap unawain kaysa sa mabagal na pagbawi.

3. Kung hindi bumalik ang volume, kumonekta nang sadya sa pamamagitan ng Go, pagkatapos ng Connect to Server, at ang kilalang address ng server, halimbawa smb://files.corp.example/team.

4. Mag-sign in gamit ang account ng file server, na isang hiwalay na desisyon sa kredensyal mula sa pag-log in sa VPN, at tiyakin ang kalagayan ng dokumento sa aplikasyon bago magpatuloy.

Ang gabay ng Apple sa pagkonekta gamit ang Finder ay nagdodokumento ng paraan ng tahasang address, at iyon ang mapagkakatiwalaang landas dito. Ang pangalan ng volume sa sidebar ay naka-cache na label, hindi ebidensya na ang dating koneksyon ay magagamit pa.

Bakit hindi makakapangako ang bagong sesyon ng bukas na handle

May mga mekanismo talaga ang SMB para makaligtas sa pansamantalang pagkadiskonekta, at pareho itong may kondisyon. Ang matibay na pagbubukas ay maaaring muling ikonekta sa loob ng time window na napagkasunduan ng client at server, habang ang tuloy-tuloy na pagbubukas ay nangangailangan ng mas mahigpit na kakayahan sa magkabilang panig. Ang pagsang-ayon ng isang Mac client at file server na i-mount ang isang share ay walang sinasabi tungkol sa kung napagkasunduan ang alinman sa mga mekanismong ito para sa mga file na bukas ka.

Ang espesipikasyon ay kasing linaw tungkol sa pagkabigo: kapag hindi nagtagumpay ang pagbawi, binabalewala ang handle at inaasahang ituturing ng client ang file na sarado. Ang aplikasyong nasa gitna ng pagsulat sa sandaling iyon ay walang wastong handle na maipagpapatuloy, kahit na mabigkas muli ang share at mukhang buo ang file sa Finder.

Iyon ang dahilan kung bakit ang volume na muling lumilitaw ay kailangang hakbang at hindi sapat. Ang mga editor, aplikasyong parang database at anumang may hawak ng eksklusibong lock ay maaaring kailanganing muling buksan ang sariling koneksyon, at ang tanging mapagkakatiwalaang ulat tungkol sa kalagayan ng dokumento ay nagmumula sa aplikasyon at hindi sa listahan ng file.

Huwag pilitin ang mount na magmukhang maayos

Ang sapilitang pag-unmount sa volume o pagpatay sa mga katulong ng filesystem para linisin ang stuck na sidebar ay kaakit-akit at karaniwang kontraproduktibo. Ang stuck na kalagayan ay madalas na sumasalamin sa tunay na operasyong naghihintay, at ang paghila sa mount mula sa ilalim nito ay hindi nagdadala ng data ng aplikasyon sa anumang ligtas na lugar. Pinapahirap din nito ang susunod na imbestigasyon, dahil ang error na nakita ng gumagamit ay nabura na sa screen. Itala ang eksaktong error na iniulat ng aplikasyon at ang oras ng pagkadiskonekta, dahil ang timestamp na iyon ang nagpapahintulot sa iyong iharap ang ulat laban sa mga log ng server.

Kung nananatiling abala ang share, gamitin ang pamamaraan ng file service o ng suporta sa Mac sa halip na magtaas ng puwersa. Ang pag-iingat ng ebidensya ay mas mahalaga kaysa sa maayos na sidebar.

Bago ang susunod na planadong pagbagsak

Tapusin ang mga pag-save, isara ang mga umaasang file at normal na ilabas ang share bago sadyang idiskonekta ang VPN. Ang pagkakasunod-sunod na iyon ay mura at inaalis ang buong klase ng tanong na ito.

Para sa trabahong madalas tamaan ng pagkaantala, baguhin ang modelo ng trabaho at hindi ang mount: magtabi ng lokal na kopya at mag-sync sa pamamagitan ng mekanismong sinusuportahan ng aplikasyon, upang ang bumagsak na tunel ay magkakahalaga sa iyo ng isang agwat ng sync sa halip na hindi tiyak na pagsulat. Hindi kayang i-preserve ng mount script ang mga di-makatwirang transaksyon ng bukas na file, at walang tuning ang magpaparating dito na subukan.