¿Debe la sesión de usuario poseer el montaje SSHFS sobre VPN?

Montar una carpeta compartida después de que suba la VPN implica dos identidades que es fácil confundir: el componente autorizado a configurar la red y la cuenta autorizada a iniciar sesión en el servidor de archivos. Rara vez son la misma. Un hook de VPN propiedad de root es un mal lugar para iniciar el montaje SSHFS de un usuario de escritorio, porque no tiene ni el agente del usuario ni la propiedad de montaje prevista. Acertar primero con la propiedad hace que el disparador sea simple.

Dos identidades, dos permisos separados

El cliente VPN necesita privilegios para cambiar rutas e interfaces. El montaje SSHFS necesita una identidad SSH que el servidor de archivos acepte y un montaje FUSE propiedad de la cuenta que leerá los archivos. Un solo script ejecutado como root satisface el primer requisito y rompe en silencio el segundo.

Montar como root deja los archivos fuera de la sesión de escritorio y posiblemente sin acceso al agente que guarda la clave del usuario. El montaje existe, el usuario no puede escribir a través de él y el fallo parece un problema de permisos del servidor. Ese diagnóstico erróneo cuesta una tarde y un ticket al equipo de almacenamiento.

Decida qué cuenta posee el montaje antes de escribir cualquier automatización, porque esa elección determina dónde vive el disparador y a qué credenciales puede llegar.

Primero establezca a mano un montaje propiedad del usuario

Parta de un usuario que inició sesión con un punto de montaje vacío, una cuenta SSH autorizada y una ruta funcional al servidor a través del túnel. Un montaje manual establece la línea base que cualquier automatización debe reproducir.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

Los nombres son ejemplos, así que sustituya el host y la ruta de exportación que su servidor ofrece realmente. Verifique la clave del host mediante el proceso aprobado en esa primera conexión. Tenga en cuenta que la contraseña de la cuenta VPN no es automáticamente la credencial de la cuenta de almacenamiento, y esa es una causa habitual de intentos fallidos.

Ejecútelo como usuario normal con un punto de montaje propiedad de ese usuario. De forma predeterminada, solo la cuenta que monta llega a los archivos, y allow_other amplía esa frontera a cada usuario local. Eso es una ampliación deliberada del acceso, no una solución alternativa para la automatización.

Haga que el disparador actúe en el mismo contexto de sesión

Deje que la integración de eventos VPN admitida pida ejecutar una acción de la sesión de usuario, en lugar de suponer que una callback privilegiada puede tomar prestada una credencial de escritorio. Limite el disparador al identificador de conexión previsto y no a cualquier interfaz que se llame tun0 por casualidad. Una regla de despachador que coincide con lo incorrecto se activa en cada cambio de red, incluidos los que no tienen nada que ver con este montaje.

La acción debería confirmar el nombre de host esperado, advertir un montaje existente y hacer un intento acotado. Un bucle de sondeo que inicia un nuevo proceso SSHFS cada pocos segundos, o reintenta una petición de credenciales mientras el servidor está caído, convierte una interrupción breve en un montón de procesos atascados. Limite el intento con un tiempo de espera y un solo reintento.

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

El primer comando da el identificador de conexión que el despachador debe coincidir. Los otros dos muestran si ya hay un intento en marcha, y esa es la comprobación que evita duplicados.

Un servicio sin supervisión necesita sus propias credenciales aprobadas y su propio mecanismo de verificación de host en su propio contexto de ejecución. No puede suponer que un agente gráfico esté desbloqueado, y no debería intentar desbloquearlo.

Planifique la desconexión antes de forzar la limpieza

Para una desconexión planificada, termine las operaciones de archivos y desmonte desde el propio flujo de trabajo del usuario que monta. Apunte al punto de montaje y no al proceso, y confirme el resultado antes de informar de éxito.

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

Desmonte solo el montaje que creó este flujo de trabajo. Si está ocupado, es una decisión de la aplicación: una separación forzada que existe para que un hook devuelva éxito oculta la pérdida de datos en lugar de evitarla.

La pérdida inesperada se comporta de forma distinta. SSHFS documenta que una interrupción de red puede bloquear una operación del sistema de archivos, y la opción reconnect restaura el transporte sin restaurar los handles: un archivo abierto antes de la reconexión puede fallar en la siguiente escritura, y una escritura interrumpida no se conserva. Esa distinción importa sobre todo a los editores que mantienen un archivo abierto durante horas. Planifique un paso de reapertura en lugar de suponer la recuperación.

Pruebe el comportamiento con archivos desechables antes de confiar en él. Un directorio que reaparece después de que vuelva el túnel no demuestra que los handles anteriores o el trabajo no guardado hayan sobrevivido.