Automatic Ripping Machine (ARM) puede empaquetarse y ejecutarse como una aplicación Docker, pero eso no significa que la extracción de discos ópticos funcione correctamente en ZimaOS. El hilo de IceWhale Community de enero de 2026 llegó exactamente a esa distinción: ARM está contenedorizado, pero una extracción fiable de CD, DVD y Blu-ray requiere un acceso inusualmente profundo a la unidad óptica y a la capa de dispositivos Linux del host.
El hilo no presentó una configuración de ARM en ZimaOS confirmada como plenamente funcional. Un participante informó de que ARM no se ejecutaba correctamente y de que otro extractor de Docker producía errores de disco ilegible. La recomendación práctica de la comunidad fue extraer los discos en otro equipo Linux y guardar los archivos terminados en ZimaOS mediante SMB o NFS. La documentación actual de ARM respalda el diagnóstico técnico: su configuración de Docker requiere el paso directo de dispositivos ópticos, dispositivos SCSI genéricos, UID/GID del host coincidentes y, en algunas configuraciones, el modo privilegiado y la integración con udev del host.
Por qué una aplicación Docker normal no basta para extraer discos
La mayoría de las aplicaciones NAS solo necesitan puertos de red y volúmenes de datos. La extracción de discos ópticos es diferente, porque programas como MakeMKV y ARM necesitan comunicarse directamente con el hardware de la unidad.
Los dispositivos ópticos habituales de Linux incluyen:
/dev/sr0
/dev/sg1El /dev/sr* el dispositivo expone la unidad óptica, mientras que el dispositivo correspondiente /dev/sg* Puede ser necesario un dispositivo SCSI genérico para los comandos de nivel inferior. Si el contenedor solo recibe un montaje de carpeta normal, no puede realizar esas operaciones.
Los síntomas descritos en el hilo de ZimaOS
Un usuario de la comunidad informó:
- ARM no se ejecutaba correctamente;
- otro extractor de Docker solo se iniciaba con una configuración restringida;
- syslog-ng encontró problemas de sockets y permisos;
- la extracción producía errores de disco ilegible incluso cuando se creía que el disco físico estaba en buen estado.
Otra respuesta explicó que estos síntomas eran compatibles con un acceso incompleto al hardware. /dev/sr0el acceso directo SCSI, los eventos de udev u otros permisos del nivel del host.
La documentación actual de ARM confirma los requisitos de hardware
La documentación actual de ARM indica a los usuarios que inspeccionen los dispositivos ópticos con:
lsscsi -gUna unidad puede aparecer conceptualmente así:
CD/DVD ... /dev/sr0 /dev/sg1A continuación, ARM recomienda pasar ambos dispositivos al contenedor:
--device="/dev/sr0:/dev/sr0"
--device="/dev/sg1:/dev/sg1"Consulta la documentación de Docker de ARM.
ARM también puede necesitar acceso a contenedores privilegiados
La guía actual de ARM para compilar Docker desde el código fuente incluye:
--privilegedy su documentación de resolución de problemas indica que algunos usuarios necesitan el modo privilegiado para que la inserción de discos y la extracción mediante udev funcionen correctamente.
Esta es una diferencia importante con respecto a los contenedores de servidores multimedia convencionales. El modo privilegiado otorga al contenedor amplias capacidades sobre los dispositivos del host, por lo que no debe habilitarse a la ligera en una imagen que no sea de confianza.
La automatización de la inserción de discos depende del host
ARM está diseñado para reaccionar automáticamente cuando se inserta un disco. Su documentación de Docker presupone una configuración de la unidad en el host y un comportamiento de udev que permitan activar el flujo de extracción al producirse la inserción.
La guía de resolución de problemas de ARM sugiere comprobar los registros del host para detectar el evento de inserción y confirma que un contenedor puede estar funcionando correctamente mientras la extracción automática sigue fallando si la integración de udev del host no funciona.
Referencia actual: Resolución de problemas de ARM en Docker.
Por qué MakeMKV puede fallar incluso cuando ARM ve la unidad
La documentación de ARM advierte específicamente que MakeMKV puede no detectar ni leer una unidad si solo /dev/sr0 se pasa y se omite el dispositivo genérico SCSI correspondiente.
Esto hace que el síntoma de «disco ilegible» de la discusión sobre ZimaOS sea especialmente importante. Que el host pueda leer una unidad óptica no demuestra que el contenedor tenga acceso a todas las interfaces de dispositivo que MakeMKV necesita.
ARM también requiere permisos coincidentes en el host
La documentación actual de ARM recomienda crear un arm usuario/grupo en el host y haciendo coincidir el:
ARM_UID
ARM_GIDcon esa cuenta del host. Los directorios de contenido multimedia, configuración, música y registros deben tener permisos de escritura para esa identidad.
Si los ID no coinciden, ARM puede fallar antes de que el flujo de extracción llegue siquiera a la unidad óptica.
Lo que el hilo original confirma realmente sobre ZimaOS
El hilo de discusión original no confirma que ARM sea imposible en ZimaOS para siempre. Confirma que, en enero de 2026, los participantes no tenían una configuración verificada que expusiera correctamente todos los privilegios necesarios de la unidad óptica.
Una respuesta consideraba que la principal limitación era el nivel de acceso al hardware y los dispositivos disponible para el contenedor. El autor original aceptó la solución práctica de usar una segunda máquina para extraer los discos.
No conviertas ese resultado en una afirmación general de que Docker no puede extraer discos o de que ZimaOS nunca podrá admitir ARM.
La solución práctica de la comunidad
El plan final aceptado por el autor original fue:
- Instala ARM en otra máquina Linux que tenga acceso directo a la unidad óptica.
- Extrae y transcodifica el disco allí.
- Guarda o mueve los archivos completados al almacenamiento de ZimaOS.
El destino puede ser un recurso compartido SMB o NFS montado, o los archivos pueden transferirse después de extraerlos.
Esto mantiene ZimaOS centrado en el almacenamiento y la distribución de contenido multimedia, mientras la segunda máquina se encarga del hardware óptico de bajo nivel.
ARM admite oficialmente flujos de trabajo de salida respaldados por red
La documentación de Docker de ARM señala que los volúmenes de salida pueden apuntar a recursos compartidos de red, aunque el rendimiento depende de la red y del comportamiento del montaje.
Una arquitectura habitual es:
Unidad óptica
↓
Máquina Linux con ARM
↓
Almacenamiento de trabajo temporal local
↓
Extracción completada
↓
Biblioteca multimedia SMB/NFS de ZimaOSUsar almacenamiento local temporal rápido para la fase de extracción/transcodificación y mover únicamente el resultado final al NAS puede reducir los problemas de red y bloqueo.
Si aun así quieres probar ARM directamente en ZimaOS
Antes de intentar crear una aplicación personalizada, recopila la información de los dispositivos del host:
lsscsi -g
ls -l /dev/sr*
ls -l /dev/sg*Después, verifica si la configuración de Docker de la aplicación personalizada de ZimaOS puede representar todos los requisitos documentados por ARM:
- el dispositivo óptico
/dev/sr*dispositivo; - el correspondiente
/dev/sg*dispositivo; - permisos necesarios del host y del contenedor;
- volúmenes persistentes para la configuración, los registros, la música y el contenido multimedia;
- modo privilegiado o capacidades equivalentes, si son necesarios;
- el flujo de eventos del host mediante udev utilizado para la extracción automática.
Si ZimaOS no puede exponer uno de esos requisitos mediante su modelo actual de aplicaciones, cambiar las rutas normales de los volúmenes de Docker no resolverá el fallo de extracción.
Notas sobre seguridad y fiabilidad
- Los contenedores privilegiados reciben un amplio acceso al host. Utiliza únicamente imágenes de confianza y comprende la exposición.
- No pases a ARM dispositivos del host que no estén relacionados.
- Concede a ARM acceso de escritura únicamente a los directorios que necesita.
- Utiliza un directorio de trabajo específico con suficiente espacio libre; la extracción y transcodificación ópticas pueden requerir temporalmente bastante almacenamiento.
- Haz copias de seguridad independientes del contenido multimedia completado.
Lista de comprobación de ARM en ZimaOS
- Confirma que la unidad óptica aparezca en el host de ZimaOS.
- Ejecuta
lsscsi -gy identifica ambos/dev/sr*y/dev/sg*. - Compara las capacidades de las aplicaciones personalizadas de ZimaOS con los requisitos actuales de Docker de ARM.
- Alinea ARM_UID/ARM_GID con los directorios del host con permisos de escritura.
- Verifica si están disponibles el modo privilegiado y la integración de eventos del host.
- No des por hecho que una interfaz web de ARM en funcionamiento significa que MakeMKV tiene acceso correcto a la unidad.
- Si el passthrough del dispositivo sigue siendo poco fiable, utiliza una máquina de extracción independiente y almacena el resultado final en ZimaOS.
Preguntas frecuentes sobre Automatic Ripping Machine en ZimaOS
¿Se puede instalar ARM en ZimaOS?
Se puede ejecutar en un contenedor, pero el hilo original no confirmó una configuración de extracción de ZimaOS completamente funcional porque el passthrough de la unidad óptica y los privilegios eran el problema que lo impedía.
¿Por qué el programa de extracción dice que el disco no se puede leer?
Una posible causa es un passthrough incompleto del dispositivo. La documentación actual de ARM indica que MakeMKV puede requerir tanto el dispositivo óptico /dev/sr* dispositivo y el dispositivo SCSI genérico correspondiente /dev/sg* dispositivo.
¿ARM requiere el modo privilegiado?
La documentación actual de Docker de ARM incluye el modo privilegiado en sus indicaciones de configuración y solución de problemas para algunas configuraciones. Si cada instalación lo necesita depende del host y del flujo de trabajo del dispositivo.
¿Cuál fue la solución aceptada del hilo original?
El autor original eligió instalar ARM en una segunda máquina y mover los archivos extraídos al almacenamiento del servidor ZimaOS.
