WD My Cloud OS5: guía de mantenimiento, diagnóstico y recuperación de configuraciones

A lo largo de esta serie hemos explorado diferentes aspectos del funcionamiento del Western Digital My Cloud Gen 2 con firmware My Cloud OS5.

Analizamos su arquitectura Linux, identificamos las particiones del sistema, recuperamos el botón Shutdown de la interfaz web, instalamos Boot Scripts y desarrollamos herramientas para monitorear la suspensión del disco duro.

También examinamos los procesos de mantenimiento del firmware y realizamos modificaciones para reducir determinadas operaciones que podrían interrumpir los periodos de suspensión.

En este último capítulo reuniremos los procedimientos necesarios para diagnosticar problemas, comprobar la persistencia de las personalizaciones y recuperar la configuración después de un reinicio.

La documentación corresponde a un WD My Cloud Gen 2 con firmware OS5 5.33.102.

1. Identificar el estado general del NAS

Antes de modificar cualquier configuración, conviene obtener información básica del sistema.

Los primeros comandos que utilizamos son:

echo "=== SISTEMA ==="
uname -a

echo
echo "=== MODELO ==="
xmldbc -g /hw_ver

echo
echo "=== FIRMWARE ==="
xmldbc -g /sw_ver_1

echo
echo "=== TIEMPO DE FUNCIONAMIENTO ==="
uptime

echo
echo "=== ALMACENAMIENTO ==="
df -h

Esta información permite confirmar:

La versión del kernel.
El modelo exacto del dispositivo.
La versión del firmware instalado.
El tiempo transcurrido desde el último reinicio.
El estado de ocupación de las particiones.

Estos datos son especialmente importantes después de una actualización del firmware, porque algunos componentes internos pueden cambiar entre versiones.

2. Verificar las particiones del sistema

Como explicamos en el primer capítulo, My Cloud OS5 utiliza diferentes sistemas de archivos para separar el firmware, la configuración y los datos.

En nuestro dispositivo identificamos las siguientes ubicaciones:

Dispositivo	Montaje	Función
/dev/ram0	/	Sistema raíz temporal
/dev/sda3	/boot	Archivos de arranque
/dev/sda7	/usr/local/config	Configuración persistente
/dev/loop0	/usr/local/modules	Imagen SquashFS del firmware
/dev/sda2	/mnt/HD/HD_a2	Volumen principal de datos

Para comprobar los montajes actuales:

mount | grep -E 'ram0|sda2|sda3|sda7|loop0'

Si una partición persistente no está montada, los scripts que dependen de ella pueden dejar de funcionar.

No debemos intentar repararla mediante comandos de escritura sin identificar primero la causa del problema.

3. Identificar los componentes personalizados

Durante nuestro proyecto implementamos tres conjuntos principales de archivos.

3.1. Personalizaciones de la interfaz web

Directorio:

/usr/local/config/web-overrides

Contiene:

diagnostics.html
ensure-hibernate-button.sh

El primer archivo contiene la modificación que hace visible el botón Shutdown.

El segundo es un script auxiliar para restaurar el montaje personalizado.

3.2. Configuración de Boot Scripts

Directorio:

/mnt/HD/HD_a2/Nas_Prog/bootscripts_conf

En su subdirectorio scripts.d almacenamos el script:

30-restore-shutdown-button.sh

Este archivo permite restaurar automáticamente el botón Shutdown después de reiniciar el NAS.

3.3. Monitor de suspensión del HDD

Directorio:

/mnt/HD/HD_a2/.disk-sleep-monitor

Contiene los scripts de monitoreo, el generador de reportes y el historial de actividad.

Los archivos principales son:

bin/disk-sleep-monitor.sh
bin/disk-sleep-report.sh
bin/sync-tm-safe.sh
history.log

Es importante distinguir estos archivos persistentes de los wrappers temporales que se crean durante la ejecución.

4. Diagnóstico del botón Shutdown

Uno de los problemas que resolvimos fue la desaparición del botón Shutdown después de reiniciar.

La solución utiliza un archivo HTML personalizado que se presenta sobre el archivo original mediante mount --bind.

4.1. Verificar que existe el HTML personalizado

ls -l /usr/local/config/web-overrides/diagnostics.html

Si el archivo existe, podemos comprobar la modificación JavaScript:

grep -n 'id_shutdown_td' \
/usr/local/config/web-overrides/diagnostics.html

La instrucción relevante debe contener:

$("#id_shutdown_td").show();

4.2. Comprobar el montaje

grep diagnostics.html /proc/mounts

En nuestra instalación, el resultado esperado es:

/dev/sda7 /usr/local/modules/web/pages/setting/diagnostics.html ext4 rw,relatime,stripe=128,data=ordered 0 0

Si el comando no devuelve resultados, el montaje personalizado no está activo.

4.3. Restaurar manualmente el botón

Si ambos archivos existen y el montaje no está activo, podemos ejecutar:

mount --bind \
/usr/local/config/web-overrides/diagnostics.html \
/usr/local/modules/web/pages/setting/diagnostics.html

Antes de ejecutarlo debemos verificar que no exista ya un montaje sobre el destino.

Después actualizamos la página Device Maintenance en el navegador.

El botón Shutdown debería aparecer junto al botón Reboot.

5. Diagnóstico de Boot Scripts

La restauración automática depende de la aplicación Boot Scripts 1.0.0.

Primero debemos confirmar que esté instalada y habilitada en el dashboard del NAS.

Después verificamos la existencia del script:

ls -l \
/mnt/HD/HD_a2/Nas_Prog/bootscripts_conf/scripts.d/30-restore-shutdown-button.sh

También podemos comprobar sus permisos de ejecución.

En nuestras pruebas el archivo apareció con permisos:

-rwxr-xr-x

Esto indica que el script es ejecutable.

5.1. Ejecutar una prueba manual

La interfaz de Boot Scripts incluye una función denominada Run now.

Esta función permite ejecutar los scripts instalados sin reiniciar el NAS.

Durante nuestras pruebas la aplicación informó:

30-restore-shutdown-button.sh: ok
0 failed

Esto confirmó que el script podía ejecutarse sin errores en la configuración existente.

La prueba definitiva fue reiniciar el dispositivo y comprobar que el montaje reapareciera automáticamente.

6. Recuperar el botón si Boot Scripts no funciona

Si el botón Shutdown desaparece después de reiniciar, pero el HTML personalizado continúa disponible, podemos restaurarlo manualmente.

Primero verificamos:

test -f /usr/local/config/web-overrides/diagnostics.html && echo "HTML disponible"

test -f /usr/local/modules/web/pages/setting/diagnostics.html && echo "Destino disponible"

Después comprobamos si el montaje existe:

grep diagnostics.html /proc/mounts

Si no existe, ejecutamos:

mount --bind \
/usr/local/config/web-overrides/diagnostics.html \
/usr/local/modules/web/pages/setting/diagnostics.html

Esto recupera el botón durante la sesión actual.

Posteriormente debemos investigar por qué Boot Scripts no ejecutó la automatización.

7. Diagnóstico del monitor de suspensión

El segundo componente importante de nuestras personalizaciones es el monitor del HDD.

Para comprobar que el script existe:

ls -l \
/mnt/HD/HD_a2/.disk-sleep-monitor/bin/disk-sleep-monitor.sh

Después verificamos la programación:

crontab -l | grep disk-sleep-monitor

En nuestra instalación la entrada esperada es:

*/5 * * * * /mnt/HD/HD_a2/.disk-sleep-monitor/bin/disk-sleep-monitor.sh

Esta tarea ejecuta el monitor cada cinco minutos.

7.1. Comprobar la configuración en XMLDB

También encontramos una entrada en la configuración interna del firmware.

Para consultarla:

xmldbc -g /system_mgr/crond/disk_sleep_monitor/count

En nuestro equipo devolvió:

Para consultar la ruta del script:

xmldbc -g /system_mgr/crond/disk_sleep_monitor/item:1/run

Resultado:

/mnt/HD/HD_a2/.disk-sleep-monitor/bin/disk-sleep-monitor.sh

Estas consultas son de solo lectura.

Aunque la persistencia fue comprobada, no reconstruimos desde cero el mecanismo completo de registro de tareas mediante XMLDB.

Por tanto, no debemos asumir que copiar únicamente un fragmento XML sea suficiente para instalar la tarea en otro dispositivo.

8. Verificar los wrappers temporales

El monitor de suspensión crea tres scripts auxiliares en RAM:

/tmp/quota-monitor-safe.sh
/tmp/rlog-safe.sh
/tmp/sync-tm-safe.sh

Para comprobarlos:

ls -l /tmp/*-safe.sh

Si los archivos no existen, debemos comprobar que el monitor esté registrado y funcionando.

El script principal incorpora la lógica necesaria para reconstruirlos cuando faltan.

Sin embargo, si la tarea principal no está ejecutándose, los wrappers pueden permanecer ausentes.

9. Consultar el estado físico del HDD

Para conocer el estado instantáneo del disco utilizamos:

hdparm -C /dev/sda

Los estados que encontramos durante el monitoreo fueron:

ACTIVE/IDLE: disco girando.
IDLE: disco girando, pero inactivo.
STANDBY: disco suspendido.

Es importante recordar que el reporte estadístico muestra el último estado registrado, no necesariamente el estado físico en el instante de la consulta.

Por ello, para una verificación inmediata, utilizamos hdparm -C.

10. Generar un reporte de actividad

El monitor incluye un generador de estadísticas acumuladas.

Para ejecutarlo:

/mnt/HD/HD_a2/.disk-sleep-monitor/bin/disk-sleep-report.sh

Una de las últimas mediciones obtenidas durante el proyecto fue:

Desde 2026-10-02 15:35:00:

Activo:       146.40 h  (46.6%)
Idle:         136.39 h  (43.4%)
Dormido:      31.26 h  (10.0%)
Desconocido:  0.00 h  (0.0%)
Total:        314.06 h
Despertares:  68
Estado actual: IDLE

Estos datos permiten evaluar la evolución del estado del HDD durante varios días.

Sin embargo, el reporte acumula todos los intervalos desde el primer registro disponible.

Por ello, si modificamos la configuración, debemos comparar las mediciones correspondientes al periodo posterior al cambio.

11. Diagnóstico de tareas programadas

Durante el proyecto modificamos determinadas tareas de mantenimiento.

Para consultar la programación actual:

crontab -l

Podemos localizar las tareas más relevantes mediante:

crontab -l | grep -E \
'quota|rlog|sync-tm|auto_fw|stime|PullWdlog'

En nuestra configuración utilizamos wrappers para evitar que determinadas operaciones se ejecuten mientras el disco está suspendido.

También reprogramamos algunas tareas para ejecutarlas durante la madrugada.

Si encontramos una programación diferente, primero debemos identificar si el firmware restauró alguna entrada original.

El monitor contiene comprobaciones que pueden volver a aplicar determinadas modificaciones.

12. Qué hacer cuando una personalización desaparece tras reiniciar

Durante nuestras pruebas encontramos que algunas modificaciones funcionan correctamente hasta que reiniciamos el dispositivo.

Esto ocurre porque My Cloud OS5 reconstruye determinados directorios y configuraciones durante el arranque.

Para diagnosticar el problema, conviene seguir este orden:

Confirmar que el NAS reinició correctamente.
Verificar que las particiones persistentes estén montadas.
Comprobar que los archivos personalizados existan.
Verificar sus permisos.
Confirmar que la automatización esté habilitada.
Consultar el resultado de su ejecución.
Comprobar el estado final esperado.

Es importante no reinstalar aplicaciones ni sobrescribir archivos hasta identificar cuál de estos componentes falló.

13. Diagnóstico del arranque del firmware

El proceso de arranque comienza mediante BusyBox init.

En el archivo:

/etc/inittab

Encontramos la instrucción:

::sysinit:/etc/rc.sh

Posteriormente se ejecuta:

/usr/local/modules/script/system_init

Estos componentes forman parte del proceso de inicialización.

Para examinarlos sin modificarlos:

cat /etc/inittab

grep -n 'system_init' /etc/rc.sh

Debemos evitar editar directamente estos archivos sin comprender cómo intervienen en el arranque.

Un error en una etapa temprana de inicialización puede impedir que el NAS termine de arrancar.

14. Recuperación después de una actualización de firmware

Una actualización de My Cloud OS5 puede modificar archivos originales de la interfaz, scripts internos y mecanismos de administración.

Por ello, las personalizaciones deben revisarse después de actualizar.

14.1. Identificar la nueva versión

xmldbc -g /sw_ver_1

14.2. Comparar el archivo HTML original

Nuestra personalización del botón Shutdown se basa en una copia de:

/usr/local/modules/web/pages/setting/diagnostics.html

Si el firmware cambia, la estructura del archivo podría ser diferente.

En ese caso, no conviene reutilizar automáticamente una versión antigua.

Primero debemos recuperar el archivo original de la nueva versión, compararlo con el personalizado y volver a aplicar únicamente la modificación necesaria.

Si existe un montaje mount --bind, debemos recordar que la ruta del destino muestra el archivo personalizado.

Por tanto, una comparación realizada sin retirar el montaje puede ofrecer resultados engañosos.

En nuestra investigación verificamos la diferencia montando por separado la imagen SquashFS original.

La modificación identificada consistía en una sola instrucción:

$("#id_shutdown_td").hide();

Que sustituimos por:

$("#id_shutdown_td").show();

15. Recuperar la interfaz web original

Si la modificación del HTML produce algún problema visual o funcional, podemos retirar el montaje personalizado.

Primero verificamos que existe:

grep diagnostics.html /proc/mounts

Si está activo, ejecutamos:

umount /usr/local/modules/web/pages/setting/diagnostics.html

Esto vuelve a mostrar el archivo original incluido en SquashFS.

El archivo personalizado permanece almacenado en la partición persistente.

Para evitar que reaparezca después de reiniciar, también debemos deshabilitar el script correspondiente en Boot Scripts.

16. Recuperación del monitor de suspensión

El monitor utiliza archivos almacenados en el volumen principal.

Si una reinstalación del firmware conserva dicho volumen, es posible que los scripts continúen disponibles.

Sin embargo, debemos comprobar su existencia y permisos:

ls -l /mnt/HD/HD_a2/.disk-sleep-monitor/bin

Después verificamos su programación:

crontab -l | grep disk-sleep-monitor

Si el script existe pero la tarea no está registrada, el monitor no se ejecutará automáticamente.

La restauración de la programación debe realizarse mediante un mecanismo compatible con la versión del firmware instalada.

No recomendamos reemplazar el archivo config.xml completo por una copia de otro dispositivo.

17. Qué archivos conviene conservar

Durante nuestra investigación identificamos cuatro componentes importantes para una eventual recuperación:

Archivo o directorio	Función
/usr/local/config/web-overrides	Personalización del botón Shutdown
/mnt/HD/HD_a2/Nas_Prog/bootscripts_conf	Scripts de arranque
/mnt/HD/HD_a2/.disk-sleep-monitor	Monitor, reportes e historial
/usr/local/config/config.xml	Configuración persistente del firmware

En nuestra revisión, los tres directorios personalizados ocupaban aproximadamente 184 KB en conjunto.

El archivo config.xml tenía un tamaño aproximado de 10.5 KB.

No realizamos un respaldo comprimido completo de estos componentes.

Sin embargo, identificamos sus ubicaciones para poder documentar una recuperación futura.

Advertencia: la configuración del dispositivo puede contener información sensible. No debe publicarse íntegramente en un blog ni compartirse sin revisar su contenido.

18. Diagnóstico avanzado de procesos

Si el disco permanece activo durante periodos prolongados, podemos comenzar examinando los procesos en ejecución.

ps

También podemos buscar componentes específicos:

ps | grep -E 'crond|smbd|nmbd|httpd|php-fpm'

Estos comandos permiten identificar procesos activos, pero no demuestran qué proceso está accediendo al disco físico.

Para establecer esa relación serían necesarias mediciones adicionales de entrada y salida.

Durante nuestro proyecto no llegamos a identificar de manera concluyente un único proceso responsable de la ausencia reciente de STANDBY.

19. Verificar el estado de las tareas cron

Una modificación de cron puede funcionar correctamente durante varios días y después cambiar debido a la intervención del firmware.

Por eso es recomendable realizar comprobaciones periódicas.

Para revisar las tareas principales:

echo "=== MONITOR ==="
crontab -l | grep disk-sleep-monitor

echo
echo "=== TAREAS OPTIMIZADAS ==="
crontab -l | grep -E \
'quota|rlog|sync-tm|auto_fw|stime|PullWdlog'

echo
echo "=== SCRIPTS TEMPORALES ==="
ls -l /tmp/*-safe.sh

Estas consultas permiten detectar si la programación ha cambiado o si falta alguno de los archivos auxiliares.

20. Comprobación integral del sistema

Para facilitar las revisiones, podemos reunir los principales comandos de diagnóstico en una sola secuencia.

El siguiente bloque es de solo lectura y puede ejecutarse por SSH:

echo "=================================="
echo "WD MY CLOUD OS5 - DIAGNOSTICO"
echo "=================================="

echo
echo "=== SISTEMA ==="
uname -a
uptime

echo
echo "=== MODELO Y FIRMWARE ==="
xmldbc -g /hw_ver
xmldbc -g /sw_ver_1

echo
echo "=== PARTICIONES ==="
df -h

echo
echo "=== ESTADO DEL HDD ==="
hdparm -C /dev/sda

echo
echo "=== SHUTDOWN PERSONALIZADO ==="
grep diagnostics.html /proc/mounts

echo
echo "=== BOOT SCRIPTS ==="
ls -l /mnt/HD/HD_a2/Nas_Prog/bootscripts_conf/scripts.d/

echo
echo "=== MONITOR DE SUSPENSION ==="
crontab -l | grep disk-sleep-monitor

echo
echo "=== WRAPPERS ==="
ls -l /tmp/*-safe.sh

echo
echo "=== TAREAS DE MANTENIMIENTO ==="
crontab -l | grep -E \
'quota|rlog|sync-tm|auto_fw|stime|PullWdlog'

echo
echo "=== REPORTE DE SUSPENSION ==="
/mnt/HD/HD_a2/.disk-sleep-monitor/bin/disk-sleep-report.sh

Este diagnóstico permite revisar los componentes principales de nuestra configuración sin realizar modificaciones.

Sin embargo, hay una consideración: el generador de reportes puede leer archivos almacenados en el volumen principal.

Por tanto, ejecutar el diagnóstico completo puede provocar actividad del disco si este se encontraba suspendido.

Si el objetivo es observar STANDBY sin alterar el estado del HDD, conviene comenzar únicamente con:

hdparm -C /dev/sda

21. Recomendaciones de mantenimiento

Después de varias semanas de investigación establecimos las siguientes recomendaciones:

Comprobar periódicamente la capacidad disponible.
Revisar el estado de las personalizaciones después de actualizar.
Evitar modificar directamente los archivos originales de SquashFS.
Conservar los scripts personalizados en particiones persistentes.
Documentar la programación de las tareas modificadas.
Verificar las automatizaciones después de reiniciar.
Evitar publicar archivos de configuración con información sensible.
Medir el impacto de cada modificación antes de atribuirle una mejora.
No deshabilitar procesos del firmware sin comprender su función.
Mantener procedimientos de reversión para las modificaciones importantes.

Estas prácticas permiten administrar el NAS con mayor control y facilitan la identificación de problemas posteriores.

22. Estado final de nuestro proyecto

Al concluir esta etapa de documentación, obtuvimos los siguientes resultados:

Componente	Resultado
Botón Shutdown	Recuperado y visible
Boot Scripts	Instalado y funcionando
Restauración después del reinicio	Verificada
Monitor de suspensión	Operativo
Historial de estados	Persistente
Reporte estadístico	Funcionando
Wrappers de mantenimiento	Reconstrucción verificada
Aumento sostenido de STANDBY	No demostrado
Respaldo completo de personalizaciones	No realizado

La investigación permitió comprender mejor la arquitectura de OS5 y desarrollar varias soluciones que permanecen activas después de reiniciar.

El monitoreo del disco también permitió identificar una limitación importante: la reducción de determinadas tareas programadas no ha sido suficiente para conseguir nuevos periodos prolongados de suspensión.

23. Conclusiones generales

Personalizar un WD My Cloud Gen 2 con My Cloud OS5 requiere comprender las particularidades de su arquitectura.

El firmware utiliza un sistema raíz temporal, una imagen SquashFS de solo lectura y diferentes particiones persistentes.

Esta organización explica por qué algunas modificaciones desaparecen después de reiniciar.

Durante este proyecto demostramos que es posible recuperar funciones de la interfaz administrativa, ejecutar scripts personalizados durante el arranque y construir herramientas de monitoreo utilizando las utilidades disponibles en Linux.

La recuperación del botón Shutdown fue uno de los resultados más claros: modificamos una sola instrucción JavaScript y utilizamos un montaje para presentar el archivo personalizado sin alterar la imagen del firmware.

Posteriormente, Boot Scripts permitió conservar esa funcionalidad después de reiniciar.

También desarrollamos un monitor de suspensión que registra los estados del HDD y calcula estadísticas de funcionamiento.

Aunque las optimizaciones de mantenimiento todavía no han demostrado un aumento sostenido del tiempo en STANDBY, contamos ahora con información para analizar los resultados de manera objetiva.

La principal conclusión de esta serie es que las modificaciones de un NAS deben ser pequeñas, verificables, reversibles y compatibles con los mecanismos de persistencia del firmware.

Comprender estos principios permite ampliar las capacidades del WD My Cloud sin necesidad de alterar directamente su imagen original de sistema.

Serie completa: Personalización avanzada del WD My Cloud OS5

Arquitectura del sistema, hardware y firmware.
Administración por SSH y herramientas de diagnóstico.
Recuperación del botón Shutdown oculto.
Automatización persistente mediante Boot Scripts.
Monitoreo de suspensión del disco duro.
Optimización de servicios y tareas programadas.
Almacenamiento, respaldos y sincronización de archivos.
Mantenimiento, diagnóstico avanzado y recuperación.

Esta serie documenta una configuración real del WD My Cloud Gen 2 y los resultados obtenidos durante su investigación.

Los procedimientos se probaron con firmware OS5 5.33.102. La compatibilidad con otras versiones y modelos debe verificarse antes de realizar modificaciones.

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

MBA. Juan Fernando Calderón Cabello