Beperkingen van Automatic Ripping Machine op ZimaOS

Automatic Ripping Machine (ARM) kan als Docker-applicatie worden verpakt en gestart, maar dat betekent niet dat het rippen van optische schijven correct zal werken op ZimaOS. De IceWhale Community-thread van januari 2026 kwam precies op dat onderscheid uit: ARM zelf draait in een container, maar betrouwbaar rippen van cd's, dvd's en Blu-rays vereist ongebruikelijk diepgaande toegang tot het optische station en de Linux-apparaatlaag van de host.

De thread leverde geen bevestigde, volledig werkende ARM-op-ZimaOS-configuratie op. Eén deelnemer meldde dat ARM niet correct werkte en dat een andere Docker-ripper leesbare-schijffouten produceerde. De praktische aanbeveling vanuit de community was om op een tweede Linux-machine te rippen en de voltooide bestanden via SMB of NFS op ZimaOS op te slaan. De huidige ARM-documentatie ondersteunt de technische diagnose: de Docker-configuratie verwacht doorgifte van optische apparaten, SCSI-generieke apparaten, overeenkomende UID/GID's van de host en in sommige configuraties de geprivilegieerde modus en udev-integratie met de host.

Waarom een normale Docker-app niet volstaat voor het rippen van schijven

De meeste NAS-apps hebben alleen netwerkpoorten en gegevensvolumes nodig. Optisch rippen is anders, omdat software zoals MakeMKV en ARM rechtstreeks met de hardware van het station moet communiceren.

Veelgebruikte optische apparaten onder Linux zijn:

/dev/sr0
/dev/sg1

Het /dev/sr* het apparaat stelt het optische station beschikbaar, terwijl het bijbehorende /dev/sg* Voor opdrachten op een lager niveau kan een SCSI-generiek apparaat vereist zijn. Als de container alleen een normale mapkoppeling ontvangt, kan deze die bewerkingen niet uitvoeren.

De gemelde symptomen in de ZimaOS-thread

Een communitygebruiker meldde:

ARM werkte niet succesvol;
een andere Docker-ripper startte alleen in een beperkte configuratie;
syslog-ng kreeg te maken met socket- en machtigingsproblemen;
het rippen leesbare-schijffouten veroorzaakte, zelfs wanneer men ervan uitging dat de fysieke schijf in orde was.

Een andere reactie legde uit dat deze symptomen overeenkwamen met onvolledige toegang tot /dev/sr0, SCSI-doorvoer, udev-gebeurtenissen of andere machtigingen op hostniveau.

De huidige ARM-documentatie bevestigt de hardwarevereisten

De huidige ARM Docker-documentatie instrueert gebruikers om optische apparaten te controleren met:

lsscsi -g

Een station kan er conceptueel als volgt uitzien:

cd/dvd ... /dev/sr0 /dev/sg1

ARM raadt vervolgens aan beide apparaten aan de container door te geven:

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

Zie de huidige ARM Docker-documentatie.

ARM heeft mogelijk ook toegang tot geprivilegieerde containers nodig

De huidige handleiding van ARM voor Docker vanaf de broncode bevat:

--privileged

en de documentatie voor probleemoplossing vermeldt dat sommige gebruikers de geprivilegieerde modus nodig hebben om het plaatsen van schijven en door udev aangestuurd rippen volledig te laten werken.

Dit is een belangrijk verschil met gewone containers voor mediaservers. De bevoorrechte modus geeft een container uitgebreide mogelijkheden voor toegang tot apparaten op de host en moet daarom niet zomaar worden ingeschakeld voor een niet-vertrouwde image.

Automatisering bij het plaatsen van schijven is afhankelijk van de host

ARM is ontworpen om automatisch te reageren wanneer een schijf wordt geplaatst. De Docker-documentatie verwacht configuratie van de drive op de host en udev-gedrag, zodat het plaatsen van een schijf de ripworkflow kan starten.

De ARM-probleemoplossingsgids raadt aan de hostlogs te controleren op het invoegevent en bevestigt dat een container gezond kan zijn terwijl automatisch rippen toch mislukt als de udev-integratie op de host niet werkt.

Huidige referentie: Probleemoplossing voor ARM Docker.

Waarom MakeMKV kan mislukken, zelfs als ARM de drive ziet

De ARM-documentatie waarschuwt specifiek dat MakeMKV een drive mogelijk niet kan detecteren of lezen als alleen /dev/sr0 wordt doorgegeven en het bijbehorende generieke SCSI-apparaat ontbreekt.

Daarom is het symptoom “onleesbare schijf” uit de ZimaOS-discussie bijzonder belangrijk. Een optische drive die op de host leesbaar is, bewijst niet dat de container alle apparaatinterfaces heeft die MakeMKV nodig heeft.

ARM vereist ook overeenkomende rechten op de host

De huidige ARM-documentatie raadt aan een arm gebruiker/groep op de host en de container hierop afstemmen:

ARM_UID
ARM_GID

met dat hostaccount. De mappen voor media, configuratie, muziek en logs moeten schrijfbaar zijn voor die identiteit.

Als de ID's niet overeenkomen, kan ARM al mislukken voordat de ripworkflow de optische drive bereikt.

Wat de brondraad daadwerkelijk bevestigt over ZimaOS

De brondiscussie bevestigt niet dat ARM voor altijd onmogelijk is op ZimaOS. Ze bevestigt dat de deelnemers in januari 2026 geen geverifieerde configuratie hadden waarmee alle vereiste rechten voor de optische drive succesvol beschikbaar werden gemaakt.

Eén reactie stelde dat de belangrijkste beperking lag in de mate van hardware- en apparaattoegang die voor de container beschikbaar was. De oorspronkelijke auteur stemde in met de praktische oplossing om een tweede machine voor het rippen te gebruiken.

Maak van dat resultaat geen algemene bewering dat Docker geen schijven kan rippen of dat ZimaOS ARM nooit kan ondersteunen.

De praktische oplossing van de community

Het uiteindelijke plan waarmee de oorspronkelijke auteur instemde, was:

Installeer ARM op een andere Linux-machine die rechtstreeks toegang heeft tot de optische drive.
Rip en transcodeer de schijf daar.
Sla de voltooide bestanden op in de opslag van ZimaOS of verplaats ze daarheen.

De bestemming kan een gekoppelde SMB- of NFS-share zijn, of bestanden kunnen na het rippen worden overgezet.

Hierdoor kan ZimaOS zich blijven richten op opslag en het aanbieden van media, terwijl de tweede machine de optische hardware op laag niveau afhandelt.

ARM ondersteunt officieel via het netwerk aangestuurde uitvoerworkflows

In de Dockerdocumentatie van ARM staat dat uitvoervolumes naar netwerkshares kunnen verwijzen, hoewel de prestaties afhangen van het netwerk en het gedrag van de koppeling.

Een veelgebruikte architectuur is:

Optisch station
     ↓
ARM-Linuxmachine
     ↓
Lokale tijdelijke werkopslag
     ↓
Voltooide rip
     ↓
ZimaOS SMB/NFS-med bibliotheek

Door snelle lokale tijdelijke opslag te gebruiken voor het rip- en transcodeerproces en alleen de voltooide uitvoer naar de NAS te verplaatsen, kunnen netwerk- en vergrendelingsproblemen worden verminderd.

Als je ARM toch rechtstreeks op ZimaOS wilt testen

Verzamel eerst de apparaatinformatie van de host voordat je een aangepaste app probeert te bouwen:

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

Controleer vervolgens of de aangepaste Dockerconfiguratie van ZimaOS alle vereisten kan weergeven die door ARM worden gedocumenteerd:

het optische /dev/sr* apparaat;
de bijbehorende /dev/sg* apparaat;
vereiste rechten voor host en container;
persistente volumes voor configuratie, logs, muziek en media;
de geprivilegieerde modus of gelijkwaardige mogelijkheden indien vereist;
de hostworkflow voor gebeurtenissen/udev die wordt gebruikt voor automatisch rippen.

Als ZimaOS een van deze vereisten niet kan aanbieden via het huidige applicatiemodel, zullen wijzigingen aan normale Docker-volumepaden het ripprobleem niet oplossen.

Beveiligings- en betrouwbaarheidsnotities

Geprivilegieerde containers krijgen brede toegang tot de host. Gebruik alleen vertrouwde images en begrijp de risico's.
Geef geen niet-gerelateerde hostapparaten door aan ARM.
Geef ARM alleen schrijftoegang tot de mappen die het nodig heeft.
Gebruik een speciale werkmap met voldoende vrije ruimte; optisch rippen en transcoderen kunnen tijdelijk aanzienlijke opslagruimte vereisen.
Maak onafhankelijk van de ripworkflow een back-up van voltooide media.

ARM op ZimaOS-checklist

Bevestig dat het optische station op de ZimaOS-host verschijnt.
Voer uit lsscsi -g en identificeer beide /dev/sr* en /dev/sg*.
Vergelijk de mogelijkheden van aangepaste apps in ZimaOS met de huidige Dockervereisten van ARM.
Stem ARM_UID/ARM_GID af op mappen op de host waarin kan worden geschreven.
Controleer of de geprivilegieerde modus en hostintegratie voor gebeurtenissen beschikbaar zijn.
Ga er niet van uit dat een actieve ARM-webinterface betekent dat MakeMKV correcte toegang tot het station heeft.
Als de apparaatdoorgifte onbetrouwbaar blijft, gebruik dan een aparte ripmachine en sla de voltooide uitvoer op ZimaOS op.

Veelgestelde vragen over Automatic Ripping Machine op ZimaOS

Kan ARM op ZimaOS worden geïnstalleerd?

Het kan in een container draaien, maar de oorspronkelijke thread bevestigde geen volledig werkende ripconfiguratie op ZimaOS, omdat de doorgifte van het optische station en de benodigde rechten het probleem vormden.

Waarom zegt de ripper dat de schijf onleesbaar is?

Een mogelijke oorzaak is dat de apparaatdoorgifte onvolledig is. In de huidige ARM-documentatie staat dat MakeMKV mogelijk zowel het optische /dev/sr* apparaat en de bijbehorende SCSI-generic /dev/sg* apparaat.

Heeft ARM de geprivilegieerde modus nodig?

De huidige ARM-Dockerdocumentatie vermeldt de geprivilegieerde modus in de installatie- en probleemoplossingsinstructies voor sommige configuraties. Of elke installatie deze modus nodig heeft, hangt af van de host en de workflow van het apparaat.

Wat was de geaccepteerde oplossing in de oorspronkelijke thread?

De oorspronkelijke auteur koos ervoor ARM op een tweede machine te installeren en de geripte bestanden naar de opslag op de ZimaOS-server te verplaatsen.