zfs mount es uno de esos comandos que no parecen importantes hasta que un servicio arranca y te dice que no encuentra sus datos. Entonces, de repente, una ruta vacía pasa de ser un detalle a ser el centro de tu mañana.
En Proxmox esto puede pasar con datasets usados para appdata, backups, media, compartidos por bind mount en LXC o montados dentro de una VM mediante algún invento que parecía razonable cuando lo hiciste a las doce de la noche. El servicio falla, Docker levanta contenedores sin datos, un LXC enseña un directorio vacío o una tarea de backup escribe donde no debe.
La tentación normal es culpar a Docker, a permisos, a systemd, al contenedor o a la interfaz de Proxmox. A veces es eso. Muchas otras veces el dataset simplemente no está montado donde crees.
El comando base es sencillo.
| |
Para montar un dataset concreto:
| |
Y para montar todos los datasets que deban montarse:
| |
No es un comando agresivo como destroy o rollback, pero tampoco lo lanzo sin mirar. Primero quiero saber qué datasets existen, dónde deberían montarse y qué dice ZFS de ellos.
la captura de este post#
La captura está hecha con una salida saneada. Los nombres de pool y rutas son genéricos. La idea es enseñar la lectura, no enseñar mi estructura real. No hay IPs, dominios internos ni nombres privados.
Esta es la salida usada para la captura:
| |
La historia es clara: el dataset existía, tenía mountpoint, podía montarse, pero no estaba montado. Después de zfs mount, aparece como yes y el sistema lo ve en mount.
Ese tipo de salida me ahorra bastantes vueltas.
el síntoma típico: directorio vacío#
El caso más común es muy tonto. Entras en una ruta donde esperas datos y ves un directorio vacío.
| |
Si esa ruta es el mountpoint de un dataset ZFS y el dataset no está montado, puedes estar viendo el directorio base del sistema, no el contenido real del dataset. Esto es especialmente traicionero porque la ruta existe. No hay error evidente. Solo faltan los datos.
Ese detalle puede romper servicios de formas bastante feas.
Un contenedor puede arrancar y crear carpetas nuevas en la ruta vacía. Una tarea de backup puede empezar a escribir en el disco local del nodo porque el dataset no estaba montado. Un servicio puede regenerar configuración por defecto porque no encuentra la anterior. Y tú puedes pasar media hora mirando permisos cuando el problema era más básico.
Por eso, cuando una ruta que vive en ZFS parece vacía, no empiezo por chmod. Empiezo por ZFS.
| |
Esa tabla me dice casi todo lo que necesito al principio.
mountpoint: dónde cree ZFS que debe aparecer#
La propiedad mountpoint dice dónde se monta el dataset.
| |
Si devuelve /srv/backups, ZFS intentará montar ese dataset ahí. Si devuelve none, no se montará en ninguna ruta automática. Si devuelve legacy, el montaje queda en manos de /etc/fstab o de otra capa.
En Proxmox me gusta evitar sorpresas con esto. Para datasets de uso directo, quiero rutas claras y aburridas.
| |
No uso rutas privadas raras en ejemplos ni recomiendo meter datasets bajo cualquier directorio improvisado. Si un servicio depende de esa ruta, cuanto más evidente sea, menos probabilidades hay de que el yo del futuro insulte al yo del pasado.
También conviene recordar que los zvols de VMs no se montan como datasets normales. En la captura aparece pve-zfs/vm-120-disk-0 con guiones porque no estamos hablando de un filesystem montable. Es un volumen de bloque para una VM. Intentar tratarlo como un dataset de archivos es una buena forma de perder tiempo.
canmount: puede montarse, pero quizá no debe#
canmount decide si un dataset puede montarse automáticamente.
Los valores que suelo encontrar son:
on: puede montarse normalmente.off: no se monta, aunque puede servir para heredar propiedades a hijos.noauto: no se monta automáticamente, pero puedes montarlo a mano.
Este último es muy útil para datasets que quieres tener preparados pero no siempre activos.
| |
Si un dataset tiene canmount=off, zfs mount -a no lo va a montar como esperas. Y eso puede estar bien. En ZFS es normal tener datasets padre que solo ordenan propiedades y no contienen datos útiles directamente.
El error humano es ver una ruta, asumir que debería estar montada y empezar a tocar permisos sin mirar canmount.
Yo prefiero esta lectura:
| |
En una sola tabla veo intención y estado real.
mounted: la columna que corta discusiones#
La columna mounted es seca y maravillosa.
| |
No hay mucho que debatir. El dataset no está montado.
A veces el problema es que el mountpoint no existe. A veces es que hay algo ocupando la ruta. A veces una propiedad heredada cambió. A veces el servicio arrancó antes de que ZFS terminase de montar. Y a veces alguien tocó cosas con demasiada confianza, que en homelab es una unidad de medida bastante común.
Si el dataset debería estar montado y no lo está, pruebo manualmente.
| |
Si monta sin error, reviso por qué no estaba montado antes. Si no monta, el error suele dar una pista: ruta ocupada, propiedad incorrecta, dataset no disponible, permisos del punto de montaje o pool importado de forma rara.
Después confirmo con dos lecturas.
| |
Me gusta cruzar ZFS con mount porque así separo lo que ZFS cree de lo que el sistema tiene montado.
zfs mount -a: útil, pero con cabeza#
zfs mount -a monta todos los datasets que tengan que montarse según sus propiedades.
| |
Es cómodo después de importar un pool, después de cambiar propiedades o cuando un nodo ha arrancado raro. Pero no lo uso como martillo universal. Primero miro qué va a intentar montar.
| |
Si hay muchos datasets, si algunos tienen rutas delicadas o si no tengo claro qué se va a montar, prefiero ir dataset por dataset. Es más lento, sí. También es menos propenso a convertir un problema pequeño en una búsqueda del tesoro.
En Proxmox, además, hay que pensar en servicios. Si Docker, un LXC o una tarea programada ya han escrito en la ruta vacía antes de montar el dataset, montar encima puede ocultar esos archivos. No desaparecen necesariamente, pero quedan debajo del punto de montaje. Eso confunde mucho.
Si sospecho que ha pasado, paro el servicio afectado, reviso la ruta base y decido con calma. No quiero que un contenedor siga escribiendo mientras monto y desmonto datos.
cuando el problema es el orden de arranque#
Hay fallos que solo aparecen después de reiniciar el nodo. Todo iba bien, reinicias para actualizar Proxmox, vuelve el sistema y un servicio se queja de que no encuentra datos.
Aquí hay dos posibilidades normales.
La primera: ZFS no montó el dataset.
La segunda: el dataset sí montó, pero el servicio arrancó antes y encontró la ruta vacía.
En servidores con Docker fuera de Proxmox, esto lo he visto más de una vez. En Proxmox también puede pasar con servicios del host, bind mounts en LXC o scripts propios. La solución no siempre es ZFS. A veces toca ajustar dependencias de systemd para que el servicio espere al montaje correcto.
La comprobación sigue siendo la misma.
| |
Si el dataset está montado ahora pero el servicio falló al arrancar, miro logs de ese servicio. Si el dataset no está montado, miro ZFS antes de reiniciar cosas.
no mezclar datasets con bind mounts sin documentarlo#
Los bind mounts en LXC son comodísimos. También son una fuente fantástica de confusión si no documentas qué ruta del host entra en qué contenedor.
Si un LXC espera /data y eso viene de /srv/appdata/media en el host, necesito saber si /srv/appdata/media es un directorio normal o un dataset ZFS. Si es un dataset y no está montado, el contenedor puede arrancar con una vista vacía o incompleta.
Antes de culpar al contenedor, miro el host.
| |
No hace falta complicarlo. Lo que hace falta es no saltarse capas.
Mi regla es que los datos viven primero en el host. Si el host no ve bien el dataset, el contenedor no tiene ninguna obligación moral de arreglarlo.
cambiar mountpoints sin pisarse los dedos#
Cambiar mountpoint parece fácil.
| |
Y lo es. Pero antes paro lo que dependa de esa ruta. Si hay servicios escribiendo, no quiero moverles el suelo debajo de los pies.
Mi secuencia segura suele ser:
| |
Si el servicio es un contenedor o una VM, adapto los comandos. Lo importante es el orden: parar, cambiar, montar, comprobar, arrancar.
También reviso si existe contenido previo en la nueva ruta. Montar un dataset encima de una carpeta con datos puede ocultarlos. No es el fin del mundo si sabes lo que pasa, pero es una forma bastante eficaz de asustarse gratis.
mi checklist rápido#
Cuando un dataset no aparece donde debería, hago esto:
| |
Si eso funciona, reinicio el servicio afectado y miro logs.
Si no funciona, no sigo tocando a ciegas. Leo el error exacto de zfs mount, compruebo si la ruta existe, si está ocupada, si el pool está importado correctamente y si hay propiedades heredadas que expliquen el comportamiento.
Lo bonito de esta comprobación es que no cambia datos. Montar un dataset que ya debería estar montado no es lo mismo que borrar, hacer rollback o tocar snapshots. Aun así, en storage conviene conservar cierta paranoia elegante. La terminal no premia el entusiasmo.
conclusión#
zfs mount no es el comando más sexy de ZFS. Me da igual. Es de los que uso cuando un servicio no encuentra sus datos y necesito separar un problema de montaje de un problema de aplicación.
En Proxmox, mirar mountpoint, canmount y mounted me parece obligatorio antes de culpar a Docker, LXC, permisos o al panel web. Una ruta vacía puede ser solo eso: una ruta vacía porque el dataset no está montado.
Y si algo he aprendido montando servicios en homelab es que muchas averías no son espectaculares. Son capas normales haciendo exactamente lo que les pediste, aunque tú ya no recuerdes qué les pediste.
Por eso este comando merece sitio en la caja de herramientas. Es simple, directo y te devuelve al suelo cuando el diagnóstico empieza a ponerse creativo.