Por ejemplo, nosotros hemos instalado vía Docker el conocido Pi‑hole, porque —aunque parezca mentira— todavía no lo habíamos puesto en marcha en ninguno de nuestros sistemas. Y este NAS, que va a estar encendido prácticamente todo el tiempo y cuyo consumo adicional es insignificante, es el lugar perfecto para hacerlo. Conviene recordar que Pi‑hole actúa como un filtro DNS inteligente, bloqueando publicidad, rastreadores y dominios maliciosos antes siquiera de que lleguen a nuestros dispositivos, lo que mejora la privacidad y acelera la navegación. Por todo ello, este parece el mejor momento para probarlo a fondo antes de desplegarlo también en nuestro domicilio madrileño.

A nivel de router lógicamente es necesario redirigir todas las peticiones de DNS al Pi-hole. En el caso de que el NAS estuviese apagado las peticiones irían de forma automáticva al segundo DNS (1.1.1.1 de Cloudfare).

Para no alargar esta revisión hasta el infinito y más allá, hemos creado en GitHub un repositorio con todos los ficheros de configuración, ejemplos, datos y resultados que estamos utilizando en esta prueba. De este modo, cualquier lector interesado puede consultar, descargar o adaptar nuestras configuraciones sin tener que rebuscar entre capturas o fragmentos sueltos.
Por ejemplo, aquí tenéis acceso a la configuración del docker‑compose optimizado para funcionar en este NAS de UGREEN. Conviene recordar que UGREEN utiliza lo que ellos llaman Proyectos, un sistema que no funciona mal, pero que complica un poco la vida a los puristas que preferimos herramientas “genéricas” como docker‑compose. Aun así, con un par de ajustes, todo encaja y funciona como debe.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | services: pihole: container_name: pihole image: pihole/pihole:latest networks: - pihole_net ports: - "8080:80" - "1053:53/tcp" - "1053:53/udp" environment: TZ: "Europe/Madrid" WEBPASSWORD: "admin" DNSMASQ_USER: "root" volumes: - ./etc-pihole:/etc/pihole - ./etc-dnsmasq.d:/etc/dnsmasq.d restart: unless-stopped networks: pihole_net: external: true |
Por otra parte, conviene mencionar un detalle importante: UGREEN utiliza el puerto 53 para sus máquinas virtuales, precisamente el mismo puerto que emplea Pi‑hole para ofrecer su servicio DNS. Esto no es un problema grave, pero sí un aspecto a tener en cuenta, ya que obliga a ajustar la configuración para evitar conflictos entre ambos servicios y asegurarnos de que Pi‑hole pueda funcionar con normalidad dentro del NAS. En GITHUB está explicado en detalle la forma de «liberar» el puerto 53 de UGOS para que pueda ser usado por Pi-hole.
Para completar la instalación de Pi‑hole en nuestro NAS de UGREEN hemos optado por utilizar un conjunto de listas de bloqueo muy equilibrado entre eficacia y estabilidad. En concreto, hemos añadido la conocida lista unificada de StevenBlack, la versión Small de OISD —centrada en publicidad y rastreadores— y dos listas avanzadas de HaGeZi (Pro y TIF), que amplían la protección frente a dominios maliciosos y contenido no deseado. Con esta combinación obtenemos un filtrado DNS muy completo sin penalizar el rendimiento.

Con Pi‑hole funcionando como DNS principal del sistema, el NAS filtra de forma continua todo el tráfico saliente, bloqueando casi una quinta parte de las peticiones gracias a una base de más de dos millones de dominios catalogados. En la práctica, esto se traduce en una navegación más limpia, menos rastreadores y una reducción notable de ruido en la red, algo especialmente útil en un entorno donde conviven servicios, contenedores y dispositivos domóticos que generan consultas constantes.
Una mejora especialmente interesante sería disponer de información detallada sobre qué dispositivos de nuestra red generan las consultas DNS y cuáles de ellas terminan siendo bloqueadas. Pi-hole ofrece precisamente este tipo de estadísticas, pero en nuestra instalación, con el FRITZ!Box como router principal, obtener una identificación fiable y completa de cada dispositivo no resulta tan sencillo como nos gustaría. El router tiende a actuar como intermediario de las consultas DNS, por lo que buena parte de la información que llega a Pi-hole aparece asociada al propio FRITZ!Box en lugar del equipo que originó realmente la petición. Es un aspecto que tenemos pendiente de estudiar con más detalle, ya que disponer de estadísticas individuales permitiría saber no solo cuánto bloquea Pi-hole, sino también qué dispositivos y aplicaciones son los que generan mayor cantidad de tráfico susceptible de filtrado.
2727
Si Ugreen puede pecar de algo es la «sobreprotección» que quiere dar a sus clientes evitándoles posibles problemas de seguridad … lo que no siempre es lo mejor para gente «inquieta» como nosotros-
Por ejemplo, UGOS cierra de forma automática la conexión SSH al cabo de un tiempo para proteger ataques del exterior. El problema es que cuando reseteas el NAS arranca con el SSH desactivado lo que obliga a tener que acceder vía web a la página del NAS y reactivarla de nuevo.
Sin embargo, UGOS respeta cualquier servicio que esté en:
Por ello si colocas un override de systemd ahí, no lo toca.y podrás mantener activo el servicio SSH incluso tras un apagado/encendido o un reboot.
Paso 1: crear servicio override persistente
Paso 2: crear override
Contenido:
Paso 3: recargar systemd
Resultado:
SSH queda activo
SSH se mantiene tras reboot
SSH se mantiene tras reset
SSH se mantiene tras cambio
UGOS ya no lo toca
Hemos recibido alguna pregunta sobre si hay equivalente algún procesador equivalente en Intel al R2514 de este NAS.
No hay un 1:1 perfecto. Por CPU se acerca el Intel N305 (como ya indicamos en la revisión), pero en IA/GPU el R2514 gana por goleada por cuanto Intel no tiene ROCm oficial para iGPU.
Conclusión: Si quieres IA local en NAS sin meter gráfica dedicada, AMD R2514 es hoy la única opción real de bajo consumo.
Stable Diffusion (SD): una prueba que tuvimos que abandonar
Como prueba adicional, intentamos convertir el DXP2800 GT en una pequeña estación local de generación de imágenes con Stable Diffusion aprovechando su Ryzen Embedded R2514 y su GPU integrada.
El experimento terminó siendo bastante más complicado de lo esperado: para disponer del entorno necesario tuvimos que recurrir a ROCm y a diferentes imágenes Docker de AMD, acumulando más de 50 GB de software, pero no conseguimos llegar a una instalación funcional y estable que permitiera realizar pruebas de rendimiento con Stable Diffusion.
En uno de los intentos, además, el sistema llegó a quedar completamente bloqueado, hasta el punto de que no respondía ni siquiera a un ping y fue necesario cortar la alimentación.
Consultado el servicio técnico de UGREEN, la respuesta confirmó nuestras dudas: el fabricante no ofrece soporte específico para este escenario ni una vía documentada para utilizar Stable Diffusion/ROCm de forma local sobre este NAS.
Ante la ausencia de soporte oficial, los problemas de compatibilidad encontrados y, sobre todo, el riesgo de comprometer la estabilidad de un equipo que utilizamos para otras tareas, decidimos no continuar forzando el experimento.
Por tanto, esta prueba debe considerarse un intento fallido de instalación, y no un benchmark negativo del DXP2800 GT: sencillamente, no llegamos a disponer de un entorno suficientemente fiable como para obtener resultados comparables o sacar conclusiones técnicas serias
Como en PcDeMaNo no renunciamos a nuestras «ideas» por muiy descabelladas que parezcan vamos a intentar CONVERTIR este NAS de Ugreen en un monstruo con dos cabezas:
La mayor parte del tiempo funcionando como NAS gracias a su UGOS instalado en la eMMC y para uso ocasional como PC multimedia con KODI o como «laboratorio» de desarrollo de IA (con Stable Diffusion en uno de sus NVMe.
¿Funcionará? Ya os iremos contando sobre nuestros avances
Mucho me temo que cuando por fin tengamos reconvertido nuestro NAS en el centro multimedia definitivo, con KODI arrancando más rápido que un Raspberry sin tarjetas corruptas y el HDMI echando humo de lo bien que va… será justo cuando toque volver a los cuarteles de invierno y dejar el invento reposando, como buen aparato pcdemanero que solo se usa cuando el pueblo lo reclama.
Porque esto es marca de la casa: uno se pega la paliza de configurar el sisetma operativo alternativo, pelearse con permisos, montar volúmenes, ajustar WOL, revisar logs y domar servicios como si fueran cabras… y cuando ya está niquelado, cuando ya funciona espídico, cuando ya abre las pelis antes de que las pienses… va y llega el momento de guardarlo “para cuando haga falta”.
Eso sí: lo dejaremos listo para las Navidades o para el verano, que es cuando el personal se junta, se enciende el NAS, se abre Kodi y se disfruta del cine como Dios manda: en 4K, con refresco automático..
Al menos dejamos comprobado que la instalación de la tarjeta WiFi‑USB es tan pcdemanera como prometía: se mete hasta el fondo, hace clic espiritual, el kernel la mira, la reconoce, y a funcionar. Sin dramas, sin firmware exótico, sin tener que invocar a San Torvalds.
Ya tenemos funcionando nuestro increíble NAS de UGREEN convertido, por fin, en ese cacharrito mutante que siempre soñamos: Debian 13 arrancando como un tiro desde el NVMe y KODI sirviendo pelis en 4K sin perder ni un solo fotograma, gracias a la excelente GPU integrada que afortunadamente UGREEN decidió incluir en este aparato tan peculiar.
Y lo mejor de todo: cuando nos cansamos de hacer de cineastas manchegos, basta un reinicio para que el equipo vuelva a comportarse como un NAS tradicional, estable, silencioso y obediente, exactamente igual de bien que siempre.
En unos días tendréis nuestra revisión completa, donde contaremos todas las alegrías, sorpresas y pequeñas batallas técnicas que han hecho posible esta transformación.
Esperamos que os guste tanto como a nosotros
A ver, gente… me temo que tarde o temprano tendremos que dejar de destripar nuevas perversiones tecnológicas para este NAS y ponernos a escribir la revisión prometida.
Porque lo último que se nos ha ocurrido —y esto ya roza el delito informático con premeditación y alevosía— ha sido meter KODI en el UGREEN y convertirlo en un monstruo multimedia que ríete tú de los centros de control de la NASA.
Pero claro, no nos bastaba con eso: también hemos “incrustado” Home Assistant dentro de KODI como si fuera un addon más. Resultado: puedes estar viendo tu peli favorita mientras vigilas (y controlas) la domótica de tu casa en la misma pantalla, como si fueras el operador de una Planta química o de una Refinería de Petróleo.
Esto ya no es un NAS… es un juguete peligroso.