Pouvez-vous exécuter Automatic Ripping Machine sur ZimaOS ?

Automatic Ripping Machine (ARM) peut être empaqueté et lancé comme application Docker, mais cela ne signifie pas que l’extraction de disques optiques fonctionnera correctement sur ZimaOS. Le fil de discussion IceWhale Community de janvier 2026 est parvenu exactement à cette distinction : ARM est lui-même conteneurisé, mais une extraction fiable de CD, DVD ou Blu-ray nécessite un accès exceptionnellement étendu au lecteur optique et à la couche des périphériques Linux de l’hôte.

Le fil n’a pas abouti à une configuration ARM sur ZimaOS dont le fonctionnement complet aurait été confirmé. Un participant a signalé qu’ARM ne fonctionnait pas correctement et qu’un autre extracteur Docker produisait des erreurs de disque illisible. La recommandation pratique de la communauté était d’effectuer l’extraction sur une seconde machine Linux, puis d’enregistrer les fichiers terminés sur ZimaOS via SMB ou NFS. La documentation actuelle d’ARM confirme le diagnostic technique : sa configuration Docker nécessite le passthrough des périphériques optiques, des périphériques SCSI génériques, un UID/GID hôte correspondant et, dans certaines configurations, le mode privilégié ainsi que l’intégration d’udev sur l’hôte.

Pourquoi une application Docker normale ne suffit pas pour extraire des disques

La plupart des applications NAS ont seulement besoin de ports réseau et de volumes de données. L’extraction optique est différente, car des logiciels comme MakeMKV et ARM doivent communiquer directement avec le matériel du lecteur.

Les périphériques optiques Linux courants incluent :

/dev/sr0
/dev/sg1

Le /dev/sr* Le périphérique expose le lecteur optique, tandis que le périphérique correspondant /dev/sg* Un périphérique SCSI générique peut être requis pour les commandes de bas niveau. Si le conteneur ne reçoit qu’un montage de dossier normal, il ne peut pas effectuer ces opérations.

Les symptômes signalés dans le fil ZimaOS

Un membre de la communauté a signalé :

• ARM ne fonctionnait pas correctement ;
• un autre extracteur Docker ne démarrait que dans une configuration restreinte ;
• syslog-ng rencontrait des problèmes de socket et d’autorisations ;
• L’extraction produisait des erreurs de disque illisible, même lorsque le disque physique était réputé en bon état.

Une autre réponse expliquait que ces symptômes correspondaient à un accès incomplet à l’extraction. /dev/sr0, le passthrough SCSI, les événements udev ou d’autres autorisations au niveau de l’hôte.

La documentation actuelle d’ARM confirme les exigences matérielles

La documentation Docker actuelle d’ARM indique aux utilisateurs d’inspecter les périphériques optiques avec :

lsscsi -g

Un lecteur peut apparaître conceptuellement ainsi :

CD/DVD ... /dev/sr0 /dev/sg1

ARM recommande ensuite de transmettre les deux périphériques au conteneur :

--device="/dev/sr0:/dev/sr0"
--device="/dev/sg1:/dev/sg1"

Consultez la documentation Docker actuelle d’ARM.

ARM peut également nécessiter l’accès à un conteneur privilégié

Le guide actuel d’ARM pour compiler Docker depuis les sources inclut :

--privileged

et sa documentation de dépannage indique que certains utilisateurs ont besoin du mode privilégié pour que l’insertion des disques et l’extraction pilotée par udev fonctionnent correctement.

Il s’agit d’une différence majeure par rapport aux conteneurs ordinaires de serveurs multimédias. Le mode privilégié donne à un conteneur de larges capacités d’accès aux périphériques de l’hôte ; il ne devrait donc pas être activé à la légère pour une image non fiable.

L’automatisation de l’insertion des disques dépend de l’hôte

ARM est conçu pour réagir automatiquement lorsqu’un disque est inséré. Sa documentation Docker prévoit une configuration du lecteur côté hôte et un comportement udev permettant à l’insertion de déclencher le processus d’extraction.

Le guide de dépannage d’ARM suggère de vérifier les journaux de l’hôte pour détecter l’événement d’insertion et confirme qu’un conteneur peut être sain alors que l’extraction automatique échoue toujours si l’intégration udev de l’hôte ne fonctionne pas.

Référence actuelle : Dépannage d’ARM Docker.

Pourquoi MakeMKV peut échouer même lorsqu’ARM voit le lecteur

La documentation d’ARM avertit spécifiquement que MakeMKV peut ne pas détecter ou lire un lecteur si seul /dev/sr0 est transmis et que le périphérique SCSI générique correspondant est omis.

Cela rend particulièrement important le symptôme du « disque illisible » observé dans la discussion sur ZimaOS. Le fait qu’un lecteur optique soit lisible par l’hôte ne prouve pas que le conteneur dispose de toutes les interfaces de périphériques nécessaires à MakeMKV.

ARM nécessite également des autorisations hôte correspondantes

La documentation actuelle d’ARM recommande de créer un arm utilisateur/groupe sur l’hôte et en alignant ceux du conteneur :

ARM_UID
ARM_GID

avec ce compte hôte. Les répertoires media, config, music et log doivent être accessibles en écriture pour cette identité.

Si les identifiants ne correspondent pas, ARM peut échouer avant même que le processus d’extraction n’atteigne le lecteur optique.

Ce que le fil de discussion source confirme réellement à propos de ZimaOS

La discussion source ne confirme pas qu’ARM est définitivement impossible sur ZimaOS. Elle confirme qu’en janvier 2026, les participants ne disposaient pas d’une configuration vérifiée exposant correctement tous les privilèges requis pour le lecteur optique.

Une réponse estimait que la principale limitation venait du niveau d’accès au matériel et aux périphériques disponible pour le conteneur. L’auteur d’origine a accepté la solution pratique consistant à utiliser une seconde machine pour l’extraction.

Ne transformez pas ce résultat en affirmation générale selon laquelle Docker ne peut pas extraire le contenu des disques, ou que ZimaOS ne pourra jamais prendre ARM en charge.

La solution pratique de la communauté

Le plan final accepté par l’auteur d’origine était le suivant :

1. Installez ARM sur une autre machine Linux disposant d’un accès direct au lecteur optique.
2. Extrayez et transcodez le disque à cet endroit.
3. Enregistrez ou déplacez les fichiers terminés vers le stockage de ZimaOS.

La destination peut être un partage SMB ou NFS monté, ou les fichiers peuvent être transférés après l’extraction.

Cela permet à ZimaOS de rester concentré sur le stockage et la diffusion multimédia, tandis que la seconde machine gère le matériel optique de bas niveau.

ARM prend officiellement en charge les flux de travail avec sortie sur le réseau

La documentation Docker d’ARM indique que les volumes de sortie peuvent pointer vers des partages réseau, bien que les performances dépendent du réseau et du comportement du montage.

Une architecture courante est la suivante :

Lecteur optique
     ↓
Machine Linux ARM
     ↓
Stockage de travail temporaire local
     ↓
Extraction terminée
     ↓
Bibliothèque multimédia SMB/NFS de ZimaOS

L’utilisation d’un stockage temporaire local rapide pour l’étape d’extraction/transcodage et le déplacement uniquement des fichiers terminés vers le NAS peut réduire les problèmes de réseau et de verrouillage.

Si vous souhaitez toujours tester ARM directement sur ZimaOS

Avant d’essayer de créer une application personnalisée, recueillez les informations sur les périphériques de l’hôte :

lsscsi -g
ls -l /dev/sr*
ls -l /dev/sg*

Vérifiez ensuite si la configuration Docker personnalisée de ZimaOS peut représenter toutes les exigences documentées par ARM :

• le lecteur optique /dev/sr* périphérique ;
• la correspondante /dev/sg* périphérique ;
• les autorisations requises pour l’hôte et le conteneur ;
• des volumes persistants pour la configuration, les journaux, la musique et les médias ;
• le mode privilégié ou des capacités équivalentes, si nécessaire ;
• le flux d’événements côté hôte/udev utilisé pour l’extraction automatique.

Si ZimaOS ne peut pas exposer l’une de ces exigences via son modèle actuel d’applications, la modification des chemins de volumes Docker habituels ne résoudra pas l’échec de l’extraction.

Remarques sur la sécurité et la fiabilité

• Les conteneurs privilégiés bénéficient d’un accès étendu à l’hôte. Utilisez uniquement des images fiables et comprenez les risques d’exposition.
• Ne transmettez pas à ARM des périphériques hôtes sans rapport.
• Donnez à ARM un accès en écriture uniquement aux répertoires dont il a besoin.
• Utilisez un répertoire de travail dédié disposant de suffisamment d’espace libre ; l’extraction optique et le transcodage peuvent nécessiter temporairement un espace de stockage important.
• Sauvegardez les médias terminés indépendamment du processus d’extraction.

Liste de contrôle d’ARM sur ZimaOS

1. Confirmez que le lecteur optique apparaît sur l’hôte ZimaOS.
2. Exécutez lsscsi -g et identifiez les deux /dev/sr* et /dev/sg*.
3. Comparez les capacités des applications personnalisées de ZimaOS aux exigences Docker actuelles d’ARM.
4. Faites correspondre ARM_UID/ARM_GID aux répertoires hôtes accessibles en écriture.
5. Vérifiez si le mode privilégié et l’intégration des événements de l’hôte sont disponibles.
6. Ne supposez pas que l’interface Web d’ARM fonctionnelle signifie que MakeMKV dispose d’un accès correct au lecteur.
7. Si le transfert des périphériques reste peu fiable, utilisez une machine d’extraction distincte et stockez les fichiers terminés sur ZimaOS.

FAQ d’Automatic Ripping Machine sur ZimaOS

ARM peut-il être installé sur ZimaOS ?

Il peut être exécuté dans un conteneur, mais le fil de discussion source n’a pas confirmé qu’une configuration d’extraction pleinement fonctionnelle était possible sur ZimaOS, car le transfert du lecteur optique et les privilèges constituaient les obstacles.

Pourquoi le logiciel d’extraction indique-t-il que le disque est illisible ?

Une cause possible est un transfert incomplet des périphériques. La documentation actuelle d’ARM indique que MakeMKV peut nécessiter à la fois le lecteur optique /dev/sr* périphérique et le périphérique générique SCSI correspondant /dev/sg* périphérique.

ARM nécessite-t-il le mode privilégié ?

La documentation Docker actuelle d’ARM inclut le mode privilégié dans ses conseils de configuration et de dépannage pour certaines configurations. La nécessité de l’utiliser pour chaque installation dépend de l’hôte et du fonctionnement des périphériques.

Quelle était la solution acceptée du fil de discussion source ?

L’auteur original a choisi d’installer ARM sur une seconde machine et de déplacer les fichiers extraits vers le stockage du serveur ZimaOS.