Los montajes SSHFS pertenecen al usuario, no al gancho de la VPN

La suposición es fácil de absorber y difícil de notar: un gancho de conexión de la VPN se ejecuta como root, así que el montaje que inicia también debería organizarse como root. Ese razonamiento produce un directorio de equipo que el usuario del escritorio no puede abrir, un montaje que desaparece cuando el servicio disparador se reinicia y una solicitud de autenticación en un contexto donde nadie puede responderla. El gancho y el montaje son dos trabajos distintos, y solo uno de ellos necesita privilegios.

El mito: el privilegio de red implica el privilegio de montaje

Levantar una interfaz y autenticarse en un servidor de archivos son capacidades no relacionadas, y normalmente pertenecen a cuentas diferentes. El componente de la VPN necesita privilegios suficientes para cambiar rutas e interfaces. La cuenta del servidor de archivos necesita una clave o una contraseña, una decisión sobre la clave de host y un directorio personal donde montar. Entregar las credenciales del segundo trabajo a la primera identidad es como un servicio de red termina guardando la clave de un usuario.

En un portátil de un solo usuario pueden ser la misma cuenta, y esa coincidencia no es un diseño.

Una vez que un gancho privilegiado hace el montaje, tres cosas fallan en silencio. El montaje es propiedad de root, el agente del usuario no está en ese entorno y los fallos aparecen en el registro del servicio de red en lugar de en la sesión a la que le importan. Nada de eso se repara añadiendo opciones al comando de montaje. Se repara dando el trabajo a la sesión que posee la identidad.

Por qué el montaje pertenece al usuario que ha iniciado sesión

Un montaje SSHFS es un montaje FUSE propiedad del proceso que lo creó, y el acceso sigue esa propiedad en lugar del modo del directorio padre. La referencia recomienda un usuario normal con un punto de montaje que ese usuario posea, y es exactamente por eso que un montaje creado por un proceso root resulta incómodo para todos los demás. Un cambio de permisos en el punto de montaje no lo repara, porque el obstáculo es el propio dueño del montaje.

Empiece con una línea base manual dentro de la sesión del usuario: un punto de montaje vacío existente bajo el directorio personal, una cuenta autorizada en el servidor y una clave de host ya verificada mediante su proceso aprobado. Móntelo a mano una vez y úselo, porque eso demuestra que la ruta de identidad funciona antes de que exista cualquier automatización. Anote lo que necesitó el comando: el nombre de la cuenta, la ruta de exportación y el nombre de host privado. Conserve ese contexto exacto para la versión automatizada, ya que un montaje manual que funciona es la especificación que el disparador debe reproducir.

sshfs [email protected]:/exports/team "$HOME/mnt/team"

Trate cada nombre y ruta de esa línea como un marcador de posición, incluidos la cuenta y la exportación. La contraseña de una cuenta de VPN no es automáticamente la credencial de la cuenta de almacenamiento.

Qué debe pedir el disparador a la sesión

La disposición admitida es una petición del evento de red a la sesión del usuario, no una credencial prestada. Limite el disparador a la conexión que quiere, por nombre o UUID, y no a cualquier interfaz que se llame tun0 por casualidad. Ese único cambio impide que un segundo perfil, un túnel de prueba o la sesión de depuración de un compañero inicien un montaje.

La acción del lado de la sesión debería buscar el montaje existente previsto y luego hacer un único intento acotado.

No reintente en cada sondeo y no siga pidiendo una credencial mientras el servidor no sea accesible, porque ambas cosas convierten una interrupción transitoria en un bloqueo de la cuenta. Un servicio sin supervisión es un diseño aparte, con su propia credencial aprobada y su propia disposición de verificación de host en su propio contexto de ejecución, y no puede depender de que alguien haya desbloqueado un agente gráfico. Decida cuál de los dos está construyendo antes de elegir dónde vive el código. La mayor parte de la confusión aquí viene de construir uno y esperar el otro.

La desconexión es un evento del sistema de archivos, no un evento del gancho

Una desconexión planificada debería terminar las operaciones de archivos y desmontar desde la sesión del usuario que monta con el comando admitido para ese tipo de sistema de archivos. Forzar un desacoplamiento para que un gancho vuelva rápido es como las aplicaciones pierden su directorio de trabajo y los usuarios pierden la confianza en la automatización. Un montaje ocupado necesita una decisión a nivel de aplicación, como cerrar el archivo o detener la escritura, no una señal más fuerte. El estado de salida del gancho no es lo que se optimiza.

fusermount3 -u "$HOME/mnt/team"

La pérdida inesperada es un caso distinto, y SSHFS documenta que una operación interrumpida puede bloquearse mientras el transporte se reconecta.

La opción de reconexión restaura el transporte, y los archivos abiertos antes de esa reconexión aún pueden devolver errores y necesitar reapertura. Una VPN que vuelve no demuestra nada sobre manejadores anteriores ni sobre trabajo sin guardar. Elija el comportamiento que quiere ante una interrupción —pausar, mostrar un error o volver a montar a propósito— y pruébelo con archivos desechables antes de que algo dependa de él.