Recurso compartido SMB tras una caída de VPN: lista de comprobación para la recuperación

Su guardado se cuelga, el túnel cae y, treinta segundos después, la VPN vuelve a estar conectada mientras la ventana del Finder gira sobre un recurso compartido vacío. Todo parece como si debiera funcionar. El túnel está activo, la red está activa y el volumen no. Siga este orden, porque reconectar mientras una aplicación todavía cree que mantiene un identificador abierto es la forma en que una escritura incierta se convierte en una escritura perdida.

Empiece por detener el trabajo sobre el recurso compartido en lugar de reconectarlo. Eso parece pasivo y es el paso que protege sus datos.

Detenga la escritura antes de reconectar

Cierre todo lo que esté intentando escribir activamente y guarde lo que pueda en una ubicación local mediante la ruta de guardado o recuperación de la propia aplicación. No inicie una copia grande, no deje que un cliente de sincronización reintente para siempre y no acepte un aviso que ofrezca reemplazar la copia del servidor por la suya local. Esa tercera instrucción es la que cuesta datos, porque un guardado que ha expirado no está confirmado ni tampoco necesariamente ausente, y sobrescribir el archivo del servidor elimina la única prueba de lo que ocurrió en realidad.

Si la aplicación muestra dos versiones del mismo documento, deje ambas en su sitio por ahora. Elegir un ganador por nombre de archivo o por marca de tiempo es una conjetura vestida de decisión.

Restaure la ruta y luego demuéstrela

Reconecte la VPN prevista y complete su autenticación, y después confirme que el nombre del servidor de archivos se resuelve y que el servicio SMB responde a través del túnel. Un estado de conectado describe solo el túnel, así que trátelo como el comienzo de la comprobación y no como su final.

1. Confirme la resolución de nombres y el alcance del servidor de archivos a través del túnel.

2. Dé un minuto al montaje existente antes de crear otro; un segundo volumen con una etiqueta idéntica es más difícil de razonar que una recuperación lenta.

3. Si el volumen no vuelve, conéctese deliberadamente con Go, luego Connect to Server y la dirección conocida del servidor, como smb://files.corp.example/team.

4. Inicie sesión con la cuenta del servidor de archivos, que es una decisión de credenciales separada del inicio de sesión de la VPN, y confirme el estado del documento en la aplicación antes de continuar.

La guía de Apple para conectarse con el Finder documenta el método de la dirección explícita, y ese es aquí el camino fiable. Un nombre de volumen en la barra lateral es una etiqueta en caché, no una prueba de que la conexión anterior siga siendo utilizable.

Por qué una sesión nueva no puede prometer identificadores abiertos

SMB sí tiene mecanismos para sobrevivir a una desconexión temporal, y ambos son condicionales. Las aperturas duraderas pueden reconectarse dentro de una ventana de tiempo negociada entre cliente y servidor, mientras que las aperturas persistentes requieren capacidades más estrictas en ambos lados. Que un cliente Mac y un servidor de archivos acepten montar un recurso compartido no dice nada sobre si se negoció alguno de esos mecanismos para los archivos que tenía abiertos.

La especificación es igual de clara sobre el fallo: cuando la recuperación no tiene éxito, el identificador se invalida y se espera que el cliente trate el archivo como cerrado. Una aplicación que en ese momento estaba a mitad de una escritura no tiene un identificador válido del que continuar, aunque el recurso vuelva a ser explorable y el archivo parezca intacto en el Finder.

Por eso el volumen que reaparece es un paso necesario y no suficiente. Los editores, las aplicaciones de tipo base de datos y cualquier cosa que mantenga un bloqueo exclusivo pueden necesitar reabrir su propia conexión, y el único informe fiable del estado del documento viene de la aplicación y no del listado de archivos.

No fuerce el montaje a parecer ordenado

Desmontar el volumen a la fuerza o matar los auxiliares del sistema de archivos para limpiar una barra lateral atascada es tentador y suele ser contraproducente. Un estado atascado a menudo refleja una operación pendiente real, y arrancar el montaje de debajo no lleva los datos de la aplicación a ningún sitio seguro. También dificulta la siguiente investigación, porque el error que vio el usuario ya se ha borrado de la pantalla. Anote el error exacto que notificó la aplicación y la hora de la desconexión, ya que esa marca de tiempo es la que permite contrastar su informe con los registros del servidor.

Si el recurso compartido sigue ocupado, use el procedimiento del servicio de archivos o del soporte de Mac en lugar de escalar la fuerza. Preservar las pruebas vale más que una barra lateral limpia.

Antes de la próxima caída planificada

Termine los guardados, cierre los archivos dependientes y expulse el recurso compartido con normalidad antes de desconectar una VPN a propósito. Esa secuencia es barata y elimina toda esta clase de preguntas.

Para el trabajo que sufre caídas a menudo, cambie el modelo de trabajo en lugar del montaje: mantenga una copia local y sincronice mediante un mecanismo que la aplicación admita, de modo que un túnel caído le cueste un intervalo de sincronización en lugar de una escritura incierta. Un script de montaje no puede preservar transacciones arbitrarias de archivos abiertos, y ninguna cantidad de ajuste hará que lo intente.