Condivisione SMB dopo una caduta VPN: lista di controllo per il ripristino

Il salvataggio si blocca, il tunnel cade e, trenta secondi dopo, la VPN è di nuovo connessa mentre la finestra del Finder gira su una condivisione vuota. Tutto sembra come se dovesse funzionare. Il tunnel è attivo, la rete è attiva e il volume no. Seguite questo ordine, perché riconnettersi mentre un’applicazione crede ancora di tenere un handle aperto è il modo in cui una scrittura incerta diventa una scrittura perduta.

Cominciate fermando il lavoro sulla condivisione invece di riconnetterla. Sembra passivo ed è proprio il passo che protegge i vostri dati.

Fermate la scrittura prima di riconnettervi

Chiudete tutto ciò che sta attivamente tentando di scrivere e salvate quel che potete in una posizione locale tramite il percorso di salvataggio o recupero dell’applicazione stessa. Non avviate una copia grande, non lasciate che un client di sincronizzazione ritenti all’infinito e non accettate un avviso che propone di sostituire la copia del server con la vostra locale. È quel terzo avviso a costare dati, perché un salvataggio scaduto non è né confermato né necessariamente assente, e sovrascrivere il file del server elimina l’unica prova di ciò che è realmente accaduto.

Se l’applicazione mostra due versioni dello stesso documento, lasciatele entrambe al loro posto per ora. Scegliere un vincitore in base al nome del file o alla marca temporale è una congettura vestita da decisione.

Ripristinate il percorso, poi dimostratelo

Riconnettete la VPN prevista e completate la sua autenticazione, poi confermate che il nome del server di file si risolve e che il servizio SMB risponde attraverso il tunnel. Uno stato connesso descrive solo il tunnel, quindi trattatelo come l’inizio del controllo e non come la sua fine.

1. Confermate la risoluzione dei nomi e la raggiungibilità del server di file attraverso il tunnel.

2. Concedete un minuto al mount esistente prima di crearne un altro; un secondo volume con un’etichetta identica è più difficile da ragionare di un ripristino lento.

3. Se il volume non torna, connettetevi deliberatamente con Go, poi Connect to Server, e l’indirizzo noto del server, ad esempio smb://files.corp.example/team.

4. Accedete con l’account del server di file, che è una decisione sulle credenziali separata dall’accesso VPN, e confermate lo stato del documento nell’applicazione prima di continuare.

La guida di Apple per la connessione con il Finder documenta il metodo dell’indirizzo esplicito, ed è questa la via affidabile qui. Un nome di volume nella barra laterale è un’etichetta memorizzata nella cache, non la prova che la connessione precedente sia ancora utilizzabile.

Perché una sessione nuova non può promettere handle aperti

SMB ha effettivamente meccanismi per sopravvivere a una disconnessione temporanea, ed entrambi sono condizionati. Le aperture durevoli possono essere riconnesse entro una finestra temporale negoziata tra client e server, mentre le aperture persistenti richiedono capacità più rigorose su entrambi i lati. Che un client Mac e un server di file accettino di montare una condivisione non dice nulla su se uno di questi meccanismi sia stato negoziato per i file che avevate aperti.

La specifica è altrettanto chiara sul fallimento: quando il ripristino non riesce, l’handle viene invalidato e ci si aspetta che il client tratti il file come chiuso. Un’applicazione che in quel momento era a metà di una scrittura non ha un handle valido da cui continuare, anche se la condivisione è di nuovo esplorabile e il file sembra integro nel Finder.

Per questo il volume che riappare è un passo necessario e non sufficiente. Gli editor, le applicazioni di tipo database e qualunque cosa detenga un blocco esclusivo possono aver bisogno di riaprire la propria connessione, e l’unico resoconto affidabile sullo stato del documento viene dall’applicazione, non dall’elenco dei file.

Non forzate il mount a sembrare ordinato

Smontare il volume a forza o uccidere gli helper del filesystem per ripulire una barra laterale bloccata è tentante e di solito controproducente. Uno stato bloccato spesso riflette un’operazione reale in attesa, e strappare il mount da sotto non porta i dati dell’applicazione in alcun posto sicuro. Rende anche più difficile l’indagine successiva, perché l’errore visto dall’utente è già stato cancellato dallo schermo. Annotate l’errore esatto segnalato dall’applicazione e l’ora della disconnessione, perché è quella marca temporale a permettervi di confrontare il vostro resoconto con i log del server.

Se la condivisione resta occupata, usate la procedura del servizio file o del supporto Mac invece di alzare la forza. Conservare le prove vale più di una barra laterale pulita.

Prima della prossima caduta pianificata

Completate i salvataggi, chiudete i file dipendenti ed espellete la condivisione normalmente prima di disconnettere una VPN di proposito. Quella sequenza è economica ed elimina tutta questa classe di domande.

Per il lavoro che subisce spesso interruzioni, cambiate il modello di lavoro invece del mount: tenete una copia locale e sincronizzate tramite un meccanismo supportato dall’applicazione, così un tunnel caduto vi costa un intervallo di sincronizzazione invece di una scrittura incerta. Uno script di mount non può preservare transazioni arbitrarie su file aperti, e nessuna quantità di regolazione lo farà provare.