Durante bastante tiempo, mi "almacenamiento" en el homelab era básicamente un puñado de discos duros USB sueltos, cada uno colgando de un puerto distinto, cada uno con un nombre que solo yo recordaba, y cada uno un punto de fallo esperando a que le tocase el turno. Funcionaba, hasta que uno de ellos empezó a fallar y me di cuenta de que ya no podía seguir posponiendo la solución de verdad: un NAS.
Lo que no esperaba es que el camino hasta tenerlo funcionando de forma satisfactoria pasara por dos unidades antes de dar con la definitiva.
El camino hasta la unidad definitiva
La primera unidad que compré, un TerraMaster F2-425 (Intel x86 Quad-Core, 4 GB RAM), no arrancó nunca: ni un pitido, ni una luz con sentido, ni respuesta tras un reset de fábrica. Después de descartar cualquier error mío (cables, corriente, todo lo básico), quedó claro que venía defectuosa. Devolución, reembolso, y vuelta a pedir el mismo modelo.
Con la unidad de reemplazo (el mismo F2-425) ya en casa, sí arrancaba. Pero este modelo básico no tiene ninguna ranura M.2, así que instalar OMV directamente habría significado sacrificar una de las dos únicas bahías SATA — las que quería reservar por completo para discos de datos. La solución que usé mientras tanto fue instalar OMV en un SSD externo conectado por USB a través de una carcasa USB-M.2. Funcionaba, pero ese SSD externo se calentaba muchísimo con cualquier uso sostenido — nada que me diera confianza para dejarlo funcionando desatendido 24/7.
Entre eso y las ganas de no depender de un único disco compartiendo sistema operativo y datos, acabé decantándome por dar el salto a un modelo superior: el TerraMaster F2-425 Plus (Intel N95, 8 GB RAM DDR5, con 2 ranuras M.2 NVMe además de las 2 bahías SATA de 3.5"/2.5"). Esas ranuras M.2 son la clave — me permiten instalar el sistema (OpenMediaVault) en un SSD NVMe dedicado, separado por completo de los discos SATA que uso solo para datos, sin depender de un SSD externo por USB que se calienta ni de compartir disco entre sistema y almacenamiento.
Todo el paso a paso que sigue a partir de aquí es ya sobre esta unidad definitiva, el F2-425 Plus.
Segunda unidad: de TOS a OpenMediaVault
Con el F2-425 Plus en casa, la idea inicial era usar TOS, el sistema operativo propio de TerraMaster. Pero en cuanto vi la interfaz de OpenMediaVault (OMV) en capturas de otros usuarios, cambié de idea: prefiero un sistema abierto, bien documentado, y que no me ate a las decisiones de un fabricante concreto.
Instalación paso a paso
1. Preparar el USB de instalación
Descargué la ISO oficial de OMV y verifiqué su integridad antes de grabarla:
sha256sum openmediavault_8.3.1-amd64.isoComparé el resultado con el hash publicado en la web oficial, y grabé la ISO en un USB.
2. Ajustar la BIOS del NAS
Aquí llegó el primer tropiezo: la BIOS de este modelo tiene una opción "TOS Boot First" que, si está activa, siempre intenta arrancar el sistema de fábrica antes que cualquier otro dispositivo. Hubo que:
- Entrar en BIOS (tecla de acceso al arrancar, varía según modelo)
- Desactivar "TOS Boot First"
- Confirmar que Secure Boot estaba desactivado
3. Arrancar el instalador
Con el USB conectado, forcé el menú de arranque (tecla F11 o la que corresponda en tu placa) y seleccioné explícitamente el USB — dejar que arranque "por defecto" sin forzarlo puede acabar metiéndote otra vez en el menú de TOS.
4. El instalador de Debian/OMV
A partir de aquí es el instalador clásico de Debian en modo texto:
- Idioma y zona horaria
- Distribución de teclado
- Configuración de red (normalmente detecta DHCP solo — apunta la IP que te muestre)
- Nombre de host (por ejemplo
nas) - Contraseña de root
- Particionado de disco — el paso más delicado, y más aún con dos tipos de almacenamiento distintos en la misma máquina (los SSD M.2 NVMe y los discos SATA). Asegúrate de seleccionar el SSD M.2 NVMe como destino del sistema, no un disco SATA ni el USB instalador — así el sistema operativo queda completamente separado de los discos de datos. Usé el particionado guiado "usar todo el disco" sobre ese SSD
- Instalación del sistema base y de OMV
- Al terminar, reinicia y retira el USB
5. La prueba crítica: arranque automático
Con el USB ya fuera, reinicié sin tocar ninguna tecla, para comprobar si el sistema arrancaba solo en OMV o se quedaba esperando intervención manual. Tras la instalación completa (a diferencia de arrancar la ISO en vivo), el NAS sí respetó la entrada de arranque EFI de OMV y entró directo, sin pedir F11 ni nada. La lección aquí: el comportamiento de arranque de una ISO en vivo no siempre predice cómo se comportará el sistema ya instalado en disco — merece la pena probar la instalación completa antes de dar un modelo por "no apto" para un sistema alternativo.
Configurando OpenMediaVault
Con OMV arrancando solo desde el SSD M.2, tocaba la parte de configuración: preparar el NAS para servir tres servicios que antes vivían en discos USB sueltos conectados a mi Proxmox — backups de PBS, la galería de fotos de Piwigo, y las descargas de Transmission. Los dos discos SATA de 3.5"/2.5" del F2-425 Plus quedan libres exclusivamente para estos datos.
Carpetas compartidas
Sobre el disco de datos (formateado en Btrfs), creé una carpeta compartida por servicio desde el propio panel de OMV: Almacenamiento → Carpetas compartidas. Cada una queda expuesta con su propia ruta interna del tipo /srv/dev-disk-by-uuid-<UUID>/<nombre-carpeta>/.
Exports NFS
Por cada carpeta, configuré un export NFS en Servicios → NFS → Compartidos, restringido al cliente concreto que necesita acceso (mi máquina de escritorio y el host Proxmox), con estas opciones:
insecure, no_root_squash, rw, subtree_checkEl problema de permisos, y por qué ACLs en vez de `all_squash`
Mi primer intento para que mi usuario pudiera escribir en las carpetas fue usar all_squash,anonuid=1000,anongid=1000 en el export — forzar que cualquier cliente NFS llegue como un UID/GID fijo. Funcionaba, pero era una solución de brocha gorda: abría la puerta a cualquier cliente sin distinción real de usuario.
La solución más limpia fueron ACLs POSIX, que permiten dar permiso a un UID concreto sin cambiar el propietario ni el grupo de la carpeta:
setfacl -R -m u:1000:rwx /srv/dev-disk-by-uuid-<UUID>/mi-carpeta/
setfacl -R -d -m u:1000:rwx /srv/dev-disk-by-uuid-<UUID>/mi-carpeta/La segunda línea de cada par (con -d) establece el ACL por defecto, para que los ficheros nuevos que se creen dentro hereden el permiso automáticamente, no solo los ya existentes. Con eso, revertí el export a las opciones normales (subtree_check,insecure,no_root_squash, sin all_squash) y la escritura funcionó igual de bien, pero con permisos mucho más quirúrgicos.
Verificación rápida de que el ACL se aplicó:
getfacl /srv/dev-disk-by-uuid-<UUID>/mi-carpeta/Debería aparecer una línea user:1000:rwx en la salida.
El detalle que casi me despista: Transmission y NFS
Transmission vigila una carpeta en busca de ficheros .torrent nuevos usando inotify, un mecanismo de notificación de cambios del kernel de Linux. El problema: inotify no funciona de forma fiable sobre NFS — es una limitación conocida del protocolo, no un fallo de configuración.
La solución no fue montar un script con cron para vigilar la carpeta manualmente (mi primera idea), sino una opción que Transmission ya trae pensada justo para este caso: forzar el "generic watching", que comprueba la carpeta por sondeo cada 10 segundos en vez de depender de notificaciones del kernel.
systemctl stop transmission-daemon
nano /etc/transmission-daemon/settings.jsonAñadir la clave (respetando la coma de separación del JSON):
"watch-dir-force-generic": true,Y reiniciar:
systemctl start transmission-daemonCon eso, volver a soltar un .torrent en la carpeta vigilada funcionó de nuevo, sin necesidad de ningún script externo.
El resultado
Con las tres carpetas migradas y verificadas de extremo a extremo — backups de PBS llegando con normalidad, Piwigo con acceso de escritura para subir fotos, Transmission recogiendo torrents nuevos por NFS — el homelab pasó de depender de un puñado de discos USB sueltos a tener un almacenamiento centralizado de verdad, con el sistema operativo en su propio SSD M.2 separado de los datos, permisos bien definidos y sin cables sueltos por detrás del servidor.
¿Ha sido un camino sin sobresaltos? No — empezando por una unidad muerta de fábrica, siguiendo por un SSD externo que se calentaba más de la cuenta, antes incluso de llegar al modelo que finalmente se quedó. Pero el resultado final compensa con creces la paciencia que costó llegar hasta aquí.
