WD My Cloud Gen 2: arquitectura del sistema, particiones y firmware OS5

El Western Digital My Cloud Gen 2 es un dispositivo NAS que permite almacenar y compartir archivos dentro de una red. Aunque originalmente está diseñado para administrarse mediante una interfaz web, utiliza un sistema operativo Linux que ofrece posibilidades adicionales de configuración mediante SSH.

En esta serie de artículos explicaré cómo personalicé un WD My Cloud Gen 2 con firmware OS5 para recuperar funciones ocultas, automatizar tareas, monitorear el disco duro y conservar las modificaciones después de reiniciar.

El primer paso consiste en comprender cómo funciona su sistema operativo, particularmente la distribución de particiones, la imagen del firmware y los mecanismos de arranque.

1. Características del dispositivo

El equipo utilizado tiene las siguientes características:

Característica	Configuración
Fabricante	Western Digital
Modelo	My Cloud Gen 2
Identificador interno	WDMyCloud
Firmware	My Cloud OS5
Versión	5.33.102
Kernel	Linux 4.14.22
Arquitectura	ARMv7, 32 bits
Sistema de inicio	BusyBox init
Volumen principal	9.0 TiB

2. Identificación del sistema operativo

Una vez habilitado el acceso SSH desde la configuración administrativa del NAS, podemos consultar las características del sistema operativo.

2.1. Identificar el kernel

Ejecutamos el comando:

uname -a

En este dispositivo obtuvimos:

Linux WDMyCloud 4.14.22 #1 SMP Thu Oct 27 08:42:06 UTC 2022 armv7l GNU/Linux

Esto confirma que el sistema utiliza Linux con arquitectura ARMv7.

2.2. Identificar el modelo

Western Digital utiliza una herramienta llamada xmldbc para consultar y modificar determinados parámetros internos de configuración.

xmldbc -g /hw_ver

Resultado:

WDMyCloud

2.3. Consultar la versión del firmware

xmldbc -g /sw_ver_1

Resultado:

5.33.102

Estos comandos resultan útiles para identificar exactamente el dispositivo antes de instalar aplicaciones o realizar modificaciones.

3. Arquitectura del sistema operativo

Una característica importante de My Cloud OS5 es que el sistema operativo no reside completamente en una partición convencional del disco duro.

Su arquitectura combina:

• Un sistema raíz cargado en memoria RAM.
• Una imagen comprimida del firmware.
• Una partición persistente para configuraciones.
• Una partición principal para almacenar información.
• Particiones auxiliares utilizadas por el sistema.

Esta organización tiene consecuencias importantes cuando queremos modificar archivos del sistema.

3.1. Sistema raíz en memoria RAM

El sistema raíz está montado desde el dispositivo:

/dev/ram0

Podemos verificarlo mediante:

mount | grep ' on / '

Resultado:

/dev/ram0 on / type ext4 (rw,relatime,block_validity,delalloc,barrier,user_xattr,acl)

Esto significa que determinados directorios son reconstruidos durante el arranque.

Entre ellos encontramos:

/etc
/tmp
/usr/local/sbin

Consecuencia práctica: modificar archivos en estas ubicaciones no garantiza que los cambios sobrevivan a un reinicio.

Durante nuestras pruebas encontramos precisamente este problema: algunas tareas agregadas directamente al crontab desaparecían después de reiniciar el NAS.

3.2. Imagen comprimida del firmware

El firmware utiliza un sistema de archivos comprimido llamado SquashFS.

La imagen está ubicada en:

/boot/boot/image.cfs.sep

Y se encuentra montada en:

/usr/local/modules

Para comprobarlo:

mount | grep '/usr/local/modules'

Resultado:

/boot/boot/image.cfs.sep on /usr/local/modules type squashfs (ro,relatime)

La opción ro indica que el sistema está montado en modo de solo lectura.

En esta imagen se encuentran componentes importantes del firmware:

/usr/local/modules/script/system_init
/usr/local/modules/web/pages
/usr/local/modules/localsbin

Por esta razón, no es recomendable modificar directamente la imagen SquashFS para realizar personalizaciones.

3.3. Partición de configuración persistente

El dispositivo dispone de una partición que conserva información entre reinicios:

/dev/sda7

Se encuentra montada en:

/usr/local/config

Esta ubicación es especialmente importante porque permite almacenar configuraciones personalizadas.

En nuestro caso, utilizamos:

/usr/local/config/web-overrides/

En este directorio conservamos los archivos necesarios para recuperar el botón de apagado de la interfaz web.

4. Distribución de particiones

Para conocer la distribución de almacenamiento ejecutamos:

df -h

El resultado fue el siguiente:

Dispositivo	Montaje	Capacidad
/dev/root	/	53.4 MB
/dev/sda3	/boot	992.1 MB
/dev/sda7	/usr/local/config	992.1 MB
/dev/loop0	/usr/local/modules	120 MB
/dev/md0p1	/usr/local/upload	525.3 MB
/dev/sda4	/mnt/HD_a4	928.9 MB
/dev/sda2	/mnt/HD/HD_a2	9.0 TiB

El almacenamiento principal se encuentra en:

/mnt/HD/HD_a2

En esta partición se conservan los datos y diversos componentes de las aplicaciones instaladas.

También la utilizamos para almacenar los scripts de monitoreo del disco duro y sus registros históricos.

5. Funcionamiento del arranque

El WD My Cloud Gen 2 utiliza un proceso de inicialización basado en BusyBox init.

El archivo:

/etc/inittab

Contiene la siguiente instrucción:

::sysinit:/etc/rc.sh

Esto indica que el proceso de arranque comienza ejecutando:

/etc/rc.sh

Este script se encarga de preparar el sistema, montar particiones y ejecutar la inicialización principal.

Entre las operaciones identificadas se encuentra el montaje de la partición persistente:

mount /dev/sda7 /usr/local/config

Posteriormente ejecuta:

/usr/local/modules/script/system_init

5.1. Secuencia simplificada

ENCENDIDO DEL WD MY CLOUD
          |
          v
     BusyBox init
          |
          v
      /etc/rc.sh
          |
          v
  Montaje de particiones
          |
          v
 Montaje de /usr/local/config
          |
          v
       system_init
          |
          v
 Inicialización de servicios
          |
          v
 Aplicaciones y servicios NAS
          |
          v
  Interfaz web disponible

Comprender esta secuencia resulta fundamental para ejecutar scripts personalizados después de que estén disponibles los recursos necesarios.

6. Enlaces simbólicos del firmware

Durante el arranque, el firmware crea enlaces simbólicos hacia numerosos ejecutables y scripts.

Por ejemplo, encontramos esta instrucción dentro de system_init:

ln -s /usr/local/modules/localsbin/* /usr/local/sbin/.

Esto permite ejecutar programas del firmware desde ubicaciones convencionales.

Un ejemplo es:

/usr/local/sbin/custom_booting_init.sh

Que apunta a:

/usr/local/modules/localsbin/custom_booting_init.sh

Durante nuestra investigación comprobamos que este archivo existe, pero su contenido original no incorpora instrucciones personalizadas.

Aunque podría parecer un lugar adecuado para agregar comandos de arranque, presenta una limitación importante: su destino pertenece a la imagen de firmware de solo lectura.

Por ese motivo descartamos modificarlo directamente.

7. Almacenamiento temporal y persistente

Para realizar modificaciones en OS5 debemos distinguir entre las ubicaciones que se reconstruyen al arrancar y las que conservan sus archivos.

Ubicación	Tipo	Uso
/tmp	Temporal	Archivos de ejecución
/etc	Temporal	Configuración del sistema
/usr/local/sbin	Temporal	Ejecutables y enlaces
/usr/local/modules	Firmware	Imagen SquashFS
/usr/local/config	Persistente	Configuración personalizada
/mnt/HD/HD_a2	Persistente	Datos y aplicaciones

En nuestro caso, esta separación permitió desarrollar un sistema de monitoreo del disco que utiliza archivos temporales en RAM y conserva los resultados históricos en una partición persistente.

También permitió recuperar el botón de apagado mediante un archivo personalizado, sin necesidad de reconstruir la imagen original del firmware.

8. Recomendaciones antes de modificar OS5

Durante las pruebas establecimos varias recomendaciones para evitar problemas de funcionamiento:

1. Identificar exactamente el modelo y firmware antes de instalar aplicaciones.
2. Evitar modificar directamente la imagen SquashFS.
3. Guardar personalizaciones en particiones persistentes.
4. Comprobar los permisos de ejecución de los scripts.
5. Verificar cada modificación antes y después de reiniciar.
6. Documentar los comandos utilizados y sus resultados.
7. Conservar un procedimiento para revertir modificaciones.
8. Evitar tareas periódicas innecesarias que puedan despertar el disco.

Es importante recordar que algunos scripts se ejecutan con privilegios de root, por lo que un error puede afectar la disponibilidad del dispositivo.

9. Conclusiones

La arquitectura del WD My Cloud Gen 2 explica buena parte de las dificultades que encontramos al personalizar OS5.

El principal aprendizaje fue que no basta con modificar un archivo: también debemos comprender dónde se almacena y cómo se reconstruye durante el arranque.

Identificamos tres componentes fundamentales:

• SquashFS: contiene el firmware original.
• Particiones persistentes: conservan configuraciones y personalizaciones.
• Mecanismos de arranque: permiten ejecutar scripts después de reiniciar.

Comprender esta arquitectura permitió posteriormente recuperar permanentemente el botón Shutdown mediante la aplicación Boot Scripts, sin modificar la imagen original del firmware.

También sirvió de base para implementar un monitor de suspensión del disco duro y optimizar determinadas tareas programadas.

---

Continuación de la serie:

En el siguiente capítulo veremos cómo administrar el WD My Cloud mediante SSH, consultar procesos, identificar servicios y utilizar las herramientas de diagnóstico disponibles en OS5.

Documentación técnica basada en pruebas realizadas sobre un WD My Cloud Gen 2 con firmware OS5 5.33.102 durante septiembre y octubre de 2026.