La unidad -.mount está enmascarada: el cliente OpenVPN no arranca

Su servicio falla antes de que OpenVPN llegue a ejecutarse, y el error habla de una unidad de montaje que nunca configuró. Esa es la señal: systemd rechaza toda la transacción porque la unidad del montaje raíz está enmascarada, y su perfil de VPN aún no se ha leído. La causa habitual es un archivo sobrante en el directorio de unidades en tiempo de ejecución, no una fstab rota ni un certificado que falte. Siga primero el archivo, porque es la explicación más barata de descartar.

El error nombra el montaje raíz, no su perfil

systemd genera la unidad del montaje raíz a partir de la información de montaje del núcleo, y nombra la unidad -.mount porque un guion representa la ruta raíz. Esa unidad normalmente solo existe en memoria y no tiene ningún archivo detrás. Cuando el error dice que está enmascarada, algo ha puesto un archivo de unidad donde systemd lo cargará y ha apuntado ese archivo a /dev/null. La máscara es un estado real, no una errata del mensaje.

La unidad de instancia falla porque su grafo de trabajos alcanza el montaje raíz mediante el orden y mediante sus propios requisitos de montaje. La transacción se rechaza antes de que se ejecute el binario de OpenVPN, así que nada de la configuración del cliente puede ser la causa. Por eso cambiar perfiles, certificados o credenciales no tiene ningún efecto en este fallo concreto.

Revise el directorio de ejecución antes de depurar OpenVPN

Busque un archivo con ese nombre exacto en el directorio de unidades en tiempo de ejecución y luego pregunte a systemd qué cree que es la unidad. Ambas respuestas son rápidas y, juntas, separan un archivo sobrante de un problema de montaje real.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

Una máquina normal no tiene ese archivo, y la lista de enmascarados no contiene el montaje raíz. Si el primer comando imprime un enlace simbólico a /dev/null, el diagnóstico está resuelto. El mismo directorio puede contener una máscara de tmp.mount creada por las mismas herramientas, y eso produce la misma clase de fallo con otro nombre. Mire el directorio entero y no solo el nombre del error.

ls -la /run/systemd/system/*.mount

Si el directorio está limpio y la unidad sigue enmascarada, la máscara vive en otro lugar de la ruta de búsqueda, y systemctl cat -.mount mostrará qué archivo se carga.

Borre el archivo, recargue y vuelva a arrancar

Basta con quitar el archivo de ejecución y recargar el gestor, y no toca nada que venga de un paquete. Recargue antes de arrancar, porque systemd conserva el estado de la unidad cargada hasta que vuelve a leer el directorio.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

Después lea el registro del propio servicio en lugar de suponer que la corrección funcionó. Un arranque limpio solo demuestra que systemd aceptó la unidad; el cliente aún puede morir por un perfil ausente, un par inalcanzable o un certificado que no valida. Son problemas normales de OpenVPN que quedaban ocultos detrás de la unidad enmascarada. El registro anota qué perfil se cargó y si el túnel llegó a establecerse. Si la unidad arranca y el túnel no, ha pasado a otro problema, lo cual es un avance.

journalctl -u [email protected] -b --no-pager

Como /run es un sistema de archivos temporal, un reinicio también borra el archivo. Eso convierte el reinicio en una prueba útil: si el servicio funciona tras un reinicio y vuelve a fallar tras el siguiente despliegue, el archivo se está horneando en la imagen.

Evite que vuelva desde la imagen

Una plantilla de contenedor o de máquina virtual que enmascara unidades de montaje durante su construcción llevará esa máscara a cada clon. Lo siguiente que necesite el sistema de archivos se rompe, y el mensaje culpa al montaje en lugar de a la imagen de la que vino. Arreglarlo dentro de una instancia en ejecución esconde el problema hasta que se crea la instancia siguiente.

Busque en el contexto de construcción el nombre del archivo y el comando que lo crea, luego quite la máscara de la plantilla y vuelva a construir. Si la máscara es realmente necesaria durante la construcción, quítela en la misma capa que termina la construcción, para que la imagen enviada arranque limpia. Verifique en un clon nuevo y no en la máquina que reparó a mano. Es la única prueba que demuestra que la imagen cambió.

El síntoma que conviene recordar es el desajuste entre el error y lo que estaba configurando. Cuando systemd se queja de un montaje mientras arranca un cliente VPN, lea el nombre de la unidad en el mensaje antes de leer el nombre del servicio.