Automatische Ripping Machine auf ZimaOS: Docker-Limits

Automatic Ripping Machine (ARM) kann als Docker-Anwendung paketiert und gestartet werden, doch das bedeutet nicht, dass das Rippen optischer Discs unter ZimaOS korrekt funktioniert. Der IceWhale-Community-Thread vom Januar 2026 kam genau zu dieser Unterscheidung: ARM selbst läuft in einem Container, aber zuverlässiges Rippen von CDs, DVDs und Blu-rays erfordert ungewöhnlich weitreichenden Zugriff auf das optische Laufwerk und die Linux-Geräteebene des Hosts.

Der Thread lieferte keine bestätigte, vollständig funktionierende ARM-on-ZimaOS-Konfiguration. Ein Teilnehmer berichtete, dass ARM nicht korrekt lief und ein anderer Docker-Ripper Fehler wegen unlesbarer Discs erzeugte. Die praktische Empfehlung der Community lautete, auf einem zweiten Linux-Rechner zu rippen und die fertigen Dateien über SMB oder NFS auf ZimaOS zu speichern. Die aktuelle ARM-Dokumentation stützt die technische Diagnose: Das Docker-Setup erwartet die Weiterleitung optischer Geräte, generische SCSI-Geräte, eine übereinstimmende Host-UID/GID und in einigen Konfigurationen den privilegierten Modus sowie die udev-Integration des Hosts.

Warum eine normale Docker-App zum Rippen von Discs nicht ausreicht

Die meisten NAS-Apps benötigen nur Netzwerkports und Daten-Volumes. Das Rippen optischer Medien ist anders, da Software wie MakeMKV und ARM direkt mit der Laufwerkshardware kommunizieren muss.

Zu den typischen optischen Geräten unter Linux gehören:

/dev/sr0
/dev/sg1

Das /dev/sr* Das Gerät stellt das optische Laufwerk bereit, während das zugehörige /dev/sg* Ein generisches SCSI-Gerät kann für Befehle auf niedrigerer Ebene erforderlich sein. Wenn der Container nur ein normales Verzeichnis eingebunden bekommt, kann er diese Vorgänge nicht ausführen.

Die im ZimaOS-Thread gemeldeten Symptome

Ein Community-Nutzer berichtete:

ARM lief nicht erfolgreich;
ein anderer Docker-Ripper startete nur in einer eingeschränkten Konfiguration;
syslog-ng stieß auf Socket- und Berechtigungsprobleme;
Beim Rippen traten Fehler wegen unlesbarer Discs auf, obwohl man davon ausging, dass die physische Disc in Ordnung war.

Eine weitere Antwort erklärte, dass diese Symptome mit unvollständigem Zugriff vereinbar seien. /dev/sr0, SCSI-Passthrough, udev-Ereignissen oder anderen Berechtigungen auf Hostebene.

Die aktuelle ARM-Dokumentation bestätigt die Hardwareanforderungen

Die aktuelle Docker-Dokumentation von ARM weist Benutzer an, optische Geräte mit folgendem Befehl zu überprüfen:

lsscsi -g

Ein Laufwerk kann beispielsweise wie folgt erscheinen:

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

ARM empfiehlt daher, beide Geräte an den Container zu übergeben:

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

Siehe die aktuelle Docker-Dokumentation von ARM.

ARM benötigt möglicherweise ebenfalls Zugriff auf privilegierte Container

Der aktuelle Docker-Leitfaden von ARM zur Installation aus dem Quellcode enthält:

--privileged

und die Anleitung zur Fehlerbehebung besagt, dass einige Benutzer den privilegierten Modus benötigen, damit das Einlegen von Discs und das durch udev gesteuerte Rippen vollständig funktionieren.

Das ist ein wesentlicher Unterschied zu gewöhnlichen Medienserver-Containern. Der privilegierte Modus verleiht einem Container weitreichende Fähigkeiten für Host-Geräte und sollte daher nicht leichtfertig für ein nicht vertrauenswürdiges Image aktiviert werden.

Die Automatisierung beim Einlegen von Discs hängt vom Host ab

ARM ist dafür ausgelegt, automatisch zu reagieren, wenn eine Disc eingelegt wird. Die Docker-Dokumentation setzt eine laufwerksseitige Konfiguration auf dem Host und ein entsprechendes udev-Verhalten voraus, damit das Einlegen den Ripping-Workflow auslösen kann.

Der ARM-Leitfaden zur Fehlerbehebung empfiehlt, die Host-Protokolle auf das Einlegungsereignis zu prüfen, und bestätigt, dass ein Container fehlerfrei laufen kann, während das automatische Rippen weiterhin fehlschlägt, wenn die udev-Integration des Hosts nicht funktioniert.

Aktuelle Referenz: ARM-Docker-Fehlerbehebung.

Warum MakeMKV auch dann fehlschlagen kann, wenn ARM das Laufwerk erkennt

Die ARM-Dokumentation warnt ausdrücklich, dass MakeMKV ein Laufwerk möglicherweise nicht erkennt oder lesen kann, wenn nur /dev/sr0 übergeben wird und das entsprechende SCSI-Standardgerät fehlt.

Das macht das Symptom „Disc nicht lesbar“ aus der ZimaOS-Diskussion besonders wichtig. Ein vom Host lesbares optisches Laufwerk beweist nicht, dass der Container über alle Geräteschnittstellen verfügt, die MakeMKV benötigt.

ARM erfordert außerdem übereinstimmende Host-Berechtigungen

Die aktuelle ARM-Dokumentation empfiehlt, eine arm Benutzer/Gruppe auf dem Host und Anpassen von

ARM_UID
ARM_GID

mit diesem Host-Konto. Die Verzeichnisse für Medien, Konfiguration, Musik und Protokolle müssen für diese Identität beschreibbar sein.

Wenn die IDs nicht übereinstimmen, kann ARM fehlschlagen, bevor der Ripping-Workflow überhaupt das optische Laufwerk erreicht.

Was der Quellthread tatsächlich über ZimaOS bestätigt

Die Quelldiskussion bestätigt nicht, dass ARM auf ZimaOS für immer unmöglich ist. Sie bestätigt, dass die Beteiligten im Januar 2026 keine verifizierte Konfiguration hatten, die alle erforderlichen Berechtigungen für das optische Laufwerk erfolgreich bereitstellte.

Eine Antwort vertrat die Ansicht, dass die Hauptbeschränkung im Umfang des Hardware- und Gerätezugriffs des Containers lag. Der ursprüngliche Autor akzeptierte den praktischen Workaround, zum Rippen ein zweites Gerät zu verwenden.

Wandeln Sie dieses Ergebnis nicht in die pauschale Aussage um, dass Docker keine Discs rippen kann oder ZimaOS ARM niemals unterstützen wird.

Der praktische Workaround der Community

Der vom ursprünglichen Autor akzeptierte endgültige Plan lautete:

Installieren Sie ARM auf einem anderen Linux-Gerät, das direkten Zugriff auf ein optisches Laufwerk hat.
Rippen und transkodieren Sie die Disc dort.
Speichern oder verschieben Sie die fertigen Dateien in den ZimaOS-Speicher.

Das Ziel kann eine eingebundene SMB- oder NFS-Freigabe sein, oder die Dateien können nach dem Rippen übertragen werden.

So bleibt ZimaOS auf Speicher- und Medienbereitstellung fokussiert, während das zweite Gerät die optische Hardware auf niedriger Ebene verwaltet.

ARM unterstützt offiziell netzwerkbasierte Ausgabe-Workflows

In der Docker-Dokumentation von ARM wird darauf hingewiesen, dass Ausgabe-Volumes auf Netzwerkfreigaben verweisen können, wobei die Leistung vom Netzwerk und vom Mount-Verhalten abhängt.

Eine gängige Architektur ist:

Optisches Laufwerk
     ↓
ARM-Linux-Rechner
     ↓
Lokaler temporärer Arbeitsspeicher
     ↓
Fertig ausgelesene Datei
     ↓
ZimaOS-SMB/NFS-Medienbibliothek

Die Verwendung eines schnellen lokalen temporären Speichers für die Ripping-/Transkodierungsphase und das Verschieben nur der fertigen Ausgabe auf das NAS kann Netzwerk- und Sperrprobleme reduzieren.

Wenn Sie ARM weiterhin direkt auf ZimaOS testen möchten

Bevor Sie versuchen, eine benutzerdefinierte App zu erstellen, erfassen Sie die Geräteinformationen des Hosts:

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

Prüfen Sie anschließend, ob die benutzerdefinierte Docker-Konfiguration von ZimaOS alle von ARM dokumentierten Anforderungen abbilden kann:

das optische /dev/sr* Gerät;
das zugehörige /dev/sg* Gerät;
erforderliche Host-/Container-Berechtigungen;
dauerhafte Volumes für Konfiguration, Protokolle, Musik und Medien;
den privilegierten Modus oder gleichwertige Funktionen, falls erforderlich;
den hostseitigen Ereignis-/udev-Workflow, der für das automatische Auslesen verwendet wird.

Wenn ZimaOS eine dieser Anforderungen über sein aktuelles Anwendungsmodell nicht bereitstellen kann, wird das Ändern normaler Docker-Volume-Pfade den Ripping-Fehler nicht beheben.

Hinweise zu Sicherheit und Zuverlässigkeit

Privilegierte Container erhalten weitreichenden Zugriff auf den Host. Verwenden Sie nur vertrauenswürdige Images und machen Sie sich mit den damit verbundenen Risiken vertraut.
Übergeben Sie ARM keine nicht benötigten Host-Geräte.
Geben Sie ARM nur für die benötigten Verzeichnisse Schreibzugriff.
Verwenden Sie ein dediziertes Arbeitsverzeichnis mit ausreichend freiem Speicherplatz; das Auslesen optischer Medien und die Transkodierung können vorübergehend beträchtlichen Speicherplatz erfordern.
Sichern Sie fertiggestellte Medien unabhängig vom Ripping-Workflow.

ARM auf ZimaOS – Checkliste

Bestätigen Sie, dass das optische Laufwerk auf dem ZimaOS-Host angezeigt wird.
Führen Sie lsscsi -g und identifizieren Sie beide /dev/sr* und /dev/sg*.
Vergleichen Sie die Funktionen benutzerdefinierter ZimaOS-Apps mit den aktuellen Docker-Anforderungen von ARM.
Stimmen Sie ARM_UID/ARM_GID auf beschreibbare Host-Verzeichnisse ab.
Prüfen Sie, ob der privilegierte Modus und die Host-Ereignisintegration verfügbar sind.
Gehen Sie nicht davon aus, dass eine laufende ARM-WebUI bedeutet, dass MakeMKV den korrekten Laufwerkszugriff hat.
Wenn die Geräteweiterleitung weiterhin unzuverlässig ist, verwenden Sie einen separaten Ripping-Rechner und speichern Sie die fertige Ausgabe auf ZimaOS.

FAQ zu Automatic Ripping Machine auf ZimaOS

Kann ARM auf ZimaOS installiert werden?

Es kann in einem Container ausgeführt werden, aber der ursprüngliche Thread bestätigte keine vollständig funktionierende ZimaOS-Ripping-Konfiguration, da die Weiterleitung des optischen Laufwerks und die Berechtigungen das Hindernis darstellten.

Warum meldet der Ripper, dass die Disc nicht lesbar ist?

Eine mögliche Ursache ist eine unvollständige Geräteweiterleitung. Laut der aktuellen ARM-Dokumentation benötigt MakeMKV möglicherweise sowohl das optische /dev/sr* Gerät und das zugehörige generische SCSI-Gerät /dev/sg* Gerät.

Benötigt ARM den privilegierten Modus?

Die aktuelle ARM-Docker-Dokumentation umfasst für einige Konfigurationen den privilegierten Modus in ihren Einrichtungs- und Fehlerbehebungsanweisungen. Ob jede Installation ihn benötigt, hängt vom Host und vom Geräte-Workflow ab.

Wie lautete die akzeptierte Lösung im ursprünglichen Thread?

Der ursprüngliche Autor entschied sich, ARM auf einem zweiten Rechner zu installieren und die ausgelesenen Dateien in den Speicher auf dem ZimaOS-Server zu verschieben.