Recurso compartido SMB tras unha caída de VPN: lista de comprobación para a recuperación
Deixe de escribir, restaure a ruta real do servidor e trate un gardado fallido como descoñecido en lugar de perdido. Os identificadores abertos non sobreviven a unha sesión de VPN nova.
O seu gardado colga, o túnel cae e, trinta segundos despois, a VPN volve estar conectada mentres a ventá do Finder xira sobre un recurso compartido baleiro. Todo parece coma se debería funcionar. O túnel está activo, a rede está activa e o volume non. Siga esta orde, porque reconectar mentres unha aplicación aínda cre que mantén un identificador aberto é a forma en que unha escritura incerta se converte nunha escritura perdida.
Comece por deter o traballo sobre o recurso compartido en lugar de reconectalo. Iso parece pasivo e é o paso que protexe os seus datos.
Deter a escritura antes de reconectar
Peche todo o que estea a intentar escribir activamente e garde o que poida nunha localización local mediante a ruta de gardado ou recuperación da propia aplicación. Non inicie unha copia grande, non deixe que un cliente de sincronización reintente para sempre e non acepte un aviso que ofreza substituír a copia do servidor pola súa local. Ese terceiro instrutivo é o que custa datos, porque un gardado que expirou non está confirmado nin tampouco necesariamente ausente, e sobrescribir o ficheiro do servidor elimina a única proba do que ocorreu en realidade.
Se a aplicación mostra dúas versións do mesmo documento, deixe ambas no seu sitio por agora. Escoller un gañador polo nome do ficheiro ou pola marca de tempo é unha conxectura vestida de decisión.
Restaure a ruta e logo demóstrea
Reconecte a VPN prevista e complete a súa autenticación, e despois confirme que o nome do servidor de ficheiros se resolve e que o servizo SMB responde a través do túnel. Un estado de conectado describe só o túnel, así que tráteo como o comezo da comprobación e non como o seu final.
Confirme a resolución de nomes e a accesibilidade do servidor de ficheiros a través do túnel.
Dea un minuto á montaxe existente antes de crear outra; un segundo volume cunha etiqueta idéntica é máis difícil de razoar ca unha recuperación lenta.
Se o volume non volve, concéctese deliberadamente con Go, logo Connect to Server e o enderezo coñecido do servidor, como
smb://files.corp.example/team.Inicie sesión coa conta do servidor de ficheiros, que é unha decisión de credenciais separada do inicio de sesión da VPN, e confirme o estado do documento na aplicación antes de continuar.
A guía de Apple para conectarse co Finder documenta o método do enderezo explícito, e ese é aquí o camiño fiable. Un nome de volume na barra lateral é unha etiqueta na caché, non unha proba de que a conexión anterior siga sendo utilizábel.
Por que unha sesión nova non pode prometer identificadores abertos
SMB si ten mecanismos para sobrevivir a unha desconexión temporal, e ambos son condicionais. As aperturas duradeiras poden reconectarse dentro dunha xanela de tempo negociada entre cliente e servidor, mentres que as aperturas persistentes requiren capacidades máis estritas en ambos os dous lados. Que un cliente Mac e un servidor de ficheiros acepten montar un recurso compartido non di nada sobre se se negociou algún deses mecanismos para os ficheiros que tiña abertos.
A especificación é igual de clara sobre o fallo: cando a recuperación non ten éxito, o identificador invalídase e espérase que o cliente trate o ficheiro como pechado. Unha aplicación que naquel momento estaba a medio escribir non ten un identificador válido do que continuar, aínda que o recurso volva ser navegábel e o ficheiro pareza intacto no Finder.
Por iso o volume que reaparece é un paso necesario e non suficiente. Os editores, as aplicacións de tipo base de datos e calquera cousa que manteña un bloqueo exclusivo poden necesitar reabrir a súa propia conexión, e o único informe fiable do estado do documento vén da aplicación e non do listado de ficheiros.
Non force a montaxe a parecer ordenada
Desmontar o volume á forza ou matar os auxiliares do sistema de ficheiros para limpar unha barra lateral atascada é tentador e adoita ser contraproducente. Un estado atascado a miúdo reflicte unha operación pendente real, e arrincar a montaxe de debaixo non leva os datos da aplicación a ningún sitio seguro. Tamén dificulta a seguinte investigación, porque o erro que viu o usuario xa se borrou da pantalla. Anote o erro exacto que notificou a aplicación e a hora da desconexión, xa que esa marca de tempo é a que permite contrastar o seu informe cos rexistros do servidor.
Se o recurso compartido segue ocupado, use o procedemento do servizo de ficheiros ou do soporte de Mac en lugar de escalar a forza. Preservar as probas vale máis ca unha barra lateral limpa.
Antes da próxima caída planificada
Remate os gardados, peche os ficheiros dependentes e expulse o recurso compartido con normalidade antes de desconectar unha VPN a propósito. Esa secuencia é barata e elimina toda esta clase de preguntas.
Para o traballo que sofre caídas a miúdo, cambie o modelo de traballo en lugar da montaxe: manteña unha copia local e sincronice mediante un mecanismo que a aplicación admita, de xeito que un túnel caído lle custe un intervalo de sincronización en lugar dunha escritura incerta. Un script de montaxe non pode preservar transaccións arbitrarias de ficheiros abertos, e ningunha cantidade de axuste fará que o intente.