SMB-share na een VPN-uitval: een herstelchecklist

Uw opslag hangt, de tunnel valt weg en dertig seconden later is de VPN weer verbonden terwijl het Finder-venster draait op een lege share. Alles ziet eruit alsof het zou moeten werken. De tunnel staat, het netwerk staat en het volume niet. Werk dit in volgorde af, want opnieuw verbinden terwijl een toepassing nog denkt dat ze een open handle vasthoudt, is de manier waarop een onzekere schrijfactie een verloren schrijfactie wordt.

Begin met het stoppen van het werk op de share in plaats van die opnieuw te verbinden. Dat voelt passief en het is precies de stap die uw gegevens beschermt.

Stop met schrijven voordat u opnieuw verbindt

Sluit alles wat actief probeert te schrijven en sla op wat u kunt op een lokale locatie via het eigen opslag- of herstelpad van de toepassing. Start geen grote kopie, laat een synchronisatieclient niet eindeloos opnieuw proberen en accepteer geen melding die aanbiedt de serverkopie door uw lokale kopie te vervangen. Die derde instructie kost gegevens, want een opslag die is verlopen is niet bevestigd en niet noodzakelijk afwezig, en het overschrijven van het serverbestand verwijdert het enige bewijs van wat er werkelijk is gebeurd.

Als de toepassing twee versies van hetzelfde document toont, laat beide voorlopig staan. Een winnaar kiezen op bestandsnaam of tijdstempel is giswerk in het gewaad van een beslissing.

Herstel het pad en bewijs het dan

Verbind de bedoelde VPN opnieuw en rond de authenticatie af, en bevestig dan dat de naam van de bestandsserver wordt opgelost en dat de SMB-service via de tunnel antwoordt. Een status verbonden beschrijft alleen de tunnel, dus behandel dat als het begin van de controle en niet als het einde.

1. Bevestig naamresolutie en bereikbaarheid van de bestandsserver via de tunnel.

2. Geef de bestaande mount een minuut voordat u een nieuwe maakt; een tweede volume met hetzelfde label is lastiger te doordenken dan een traag herstel.

3. Als het volume wegblijft, verbind dan bewust via Go, dan Connect to Server, en het bekende adres van de server, zoals smb://files.corp.example/team.

4. Meld u aan met het bestandsserveraccount, dat is een aparte beslissing over inloggegevens, los van de VPN-login, en bevestig de documentstatus in de toepassing voordat u verdergaat.

De verbindingshandleiding van Apple voor de Finder documenteert de methode met het expliciete adres, en dat is hier het betrouwbare pad. Een volumenaam in de zijbalk is een gecachte label, geen bewijs dat de eerdere verbinding nog bruikbaar is.

Waarom een nieuwe sessie geen open handles kan beloven

SMB heeft wel mechanismen om een tijdelijke onderbreking te overleven, en beide zijn voorwaardelijk. Duurzame openingen kunnen opnieuw worden verbonden binnen een tijdvenster dat tussen client en server wordt onderhandeld, terwijl persistente openingen strengere mogelijkheden aan beide kanten vereisen. Dat een Mac-client en een bestandsserver het eens worden over het mounten van een share zegt niets over of een van beide mechanismen is onderhandeld voor de bestanden die u open had.

De specificatie is even duidelijk over falen: als het herstel niet slaagt, wordt de handle ongeldig en wordt van de client verwacht dat hij het bestand als gesloten behandelt. Een toepassing die op dat moment midden in een schrijfactie zat, heeft geen geldige handle om mee verder te gaan, ook al is de share weer doorbladerbaar en ziet het bestand er in de Finder intact uit.

Daarom is het volume dat weer verschijnt een noodzakelijke stap en geen voldoende. Editors, databasachtige toepassingen en alles wat een exclusieve vergrendeling vasthoudt, hebben mogelijk hun eigen verbinding opnieuw nodig, en het enige betrouwbare verslag van de documentstatus komt uit de toepassing en niet uit de bestandslijst.

Forceer de mount niet om er netjes uit te zien

Het volume geforceerd ontkoppelen of bestandssysteemhulpen doden om een vastgelopen zijbalk op te ruimen is verleidelijk en meestal contraproductief. Een vastgelopen toestand weerspiegelt vaak een echte wachtende bewerking, en de mount eronder vandaan trekken brengt de gegevens van de toepassing nergens veilig heen. Het maakt ook het volgende onderzoek moeilijker, omdat de fout die de gebruiker zag al van het scherm is gewist. Noteer de exacte fout die de toepassing meldde en het tijdstip van de onderbreking, want die tijdstempel is wat u uw rapport met de logs van de server laat vergelijken.

Als de share bezet blijft, gebruik dan de procedure van de bestandsservice of Mac-ondersteuning in plaats van geweld op te voeren. Bewijs bewaren is meer waard dan een nette zijbalk.

Voor de volgende geplande onderbreking

Rond opslagen af, sluit afhankelijke bestanden en werp de share normaal uit voordat u een VPN opzettelijk loskoppelt. Die volgorde is goedkoop en haalt deze hele klasse van vragen weg.

Voor werk dat vaak uitval meemaakt, verander het werkmodel in plaats van de mount: houd een lokale kopie en synchroniseer via een door de toepassing ondersteund mechanisme, zodat een weggevallen tunnel u één synchronisatie-interval kost in plaats van een onzekere schrijfactie. Een mount-script kan willekeurige transacties met open bestanden niet bewaren, en geen enkele afstelling krijgt het zover dat het het probeert.