Automatiserad rippningsmaskin på ZimaOS: Docker-begränsningar

Automatic Ripping Machine (ARM) kan paketeras och startas som en Docker-applikation, men det betyder inte att optisk skivrippning fungerar korrekt på ZimaOS. IceWhale Community-tråden från januari 2026 nådde just den distinktionen: ARM körs i en container, men tillförlitlig rippning av CD-, DVD- och Blu-ray-skivor kräver ovanligt djup åtkomst till den optiska enheten och värd-Linux-systemets enhetslager.

Tråden ledde inte till någon bekräftad fullt fungerande ARM-konfiguration på ZimaOS. En deltagare rapporterade att ARM inte kördes korrekt och att en annan Docker-rippare gav fel om oläslig skiva. Den praktiska rekommendationen från communityn var att rippa på en annan Linux-maskin och spara de färdiga filerna på ZimaOS via SMB eller NFS. Den aktuella ARM-dokumentationen stöder den tekniska diagnosen: Docker-konfigurationen förväntar sig genomströmning av optiska enheter, SCSI-generiska enheter, matchande UID/GID för värden och i vissa konfigurationer privilegierat läge samt udev-integrering med värdsystemet.

Varför en vanlig Docker-app inte räcker för skivrippning

De flesta NAS-appar behöver bara nätverksportar och datavolymer. Optisk rippning är annorlunda eftersom programvara som MakeMKV och ARM behöver kommunicera direkt med enhetens maskinvara.

Vanliga optiska Linux-enheter inkluderar:

/dev/sr0
/dev/sg1

Den /dev/sr* enheten exponerar den optiska enheten, medan den matchande /dev/sg* En SCSI-generisk enhet kan krävas för kommandon på lägre nivå. Om containern endast får en vanlig mappmontering kan den inte utföra dessa åtgärder.

Symtomen som rapporterades i ZimaOS-tråden

En användare i communityn rapporterade:

ARM kördes inte korrekt;
en annan Docker-rippare startade endast i en begränsad konfiguration;
syslog-ng stötte på problem med uttag och behörigheter;
rippning gav fel om oläslig skiva även när den fysiska skivan ansågs vara felfri.

Ett annat svar förklarade att dessa symtom stämde överens med ofullständig åtkomst till /dev/sr0, SCSI-genomströmning, udev-händelser eller andra behörigheter på värdnivå.

Den aktuella ARM-dokumentationen bekräftar maskinvarukraven

I den aktuella Docker-dokumentationen för ARM instrueras användare att undersöka optiska enheter med:

lsscsi -g

En enhet kan exempelvis visas som:

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

ARM rekommenderar sedan att båda enheterna skickas in i containern:

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

Se den aktuella Docker-dokumentationen för ARM.

ARM kan också behöva åtkomst till privilegierade containrar

ARM:s aktuella guide för att bygga Docker från källkod innehåller:

--privileged

och felsökningsdokumentationen anger att vissa användare behöver privilegierat läge för att skivinsättning och udev-styrd rippning ska fungera fullt ut.

Detta är en stor skillnad jämfört med vanliga medieservercontainrar. Privilegierat läge ger en container omfattande åtkomst till värdens enheter och bör därför inte aktiveras utan eftertanke för en otillförlitlig avbildning.

Automatisering vid skivinsättning beror på värden

ARM är utformat för att reagera automatiskt när en skiva sätts in. Dess Docker-dokumentation förutsätter konfiguration av enheten på värdsidan och udev-beteende så att insättningen kan utlösa rippningsarbetsflödet.

ARM:s felsökningsguide föreslår att man kontrollerar värdens loggar efter insättningshändelsen och bekräftar att en container kan vara frisk samtidigt som automatisk rippning ändå misslyckas om värdens udev-integration inte fungerar.

Aktuell referens: ARM:s Docker-felsökning.

Varför MakeMKV kan misslyckas även när ARM ser enheten

ARM:s dokumentation varnar specifikt för att MakeMKV kan misslyckas med att upptäcka eller läsa en enhet om endast /dev/sr0 skickas med och den matchande generiska SCSI-enheten utelämnas.

Det gör symtomet ”oläsbar skiva” från ZimaOS-diskussionen särskilt viktigt. En läsbar optisk enhet på värden bevisar inte att containern har alla enhetsgränssnitt som MakeMKV behöver.

ARM kräver också matchande behörigheter på värden

Aktuell ARM-dokumentation rekommenderar att skapa en arm användare/grupp på värden och anpassa containerns:

ARM_UID
ARM_GID

med det värdkontot. Katalogerna för media, konfiguration, musik och loggar måste vara skrivbara för den identiteten.

Om ID-numren inte överensstämmer kan ARM misslyckas innan rippningsarbetsflödet ens når den optiska enheten.

Vad källtråden faktiskt bekräftar om ZimaOS

Källtråden bekräftar inte att ARM är omöjligt på ZimaOS för alltid. Den bekräftar att deltagarna i januari 2026 inte hade någon verifierad konfiguration som framgångsrikt exponerade alla nödvändiga behörigheter för den optiska enheten.

En person trodde att den huvudsakliga begränsningen var graden av hårdvaru- och enhetsåtkomst som var tillgänglig för containern. Den ursprungliga författaren accepterade den praktiska lösningen att använda en andra maskin för rippning.

Gör inte om detta resultat till ett generellt påstående om att Docker inte kan rippa skivor eller att ZimaOS aldrig kan stödja ARM.

Gemenskapens praktiska lösning

Den slutliga planen som den ursprungliga författaren godkände var:

Installera ARM på en annan Linux-maskin som har direkt åtkomst till den optiska enheten.
Rippa och koda om skivan där.
Spara eller flytta de färdiga filerna till ZimaOS-lagringen.

Målet kan vara en monterad SMB- eller NFS-delning, eller så kan filerna överföras efter rippningen.

Detta håller ZimaOS fokuserat på lagring och medieservering, medan den andra maskinen hanterar den optiska hårdvaran på låg nivå.

ARM har officiellt stöd för utdataarbetsflöden via nätverk

ARMs Docker-dokumentation nämner att utdatavolymer kan peka på nätverksdelningar, även om prestandan beror på nätverket och monteringsbeteendet.

En vanlig arkitektur är:

Optisk enhet
     ↓
ARM Linux-dator
     ↓
Lokal temporär arbetslagring
     ↓
Färdig rippning
     ↓
ZimaOS SMB/NFS-mediebibliotek

Att använda snabb lokal temporär lagring för rippnings-/omkodningssteget och endast flytta det färdiga resultatet till NAS:en kan minska nätverks- och låsningsproblem.

Om du fortfarande vill testa ARM direkt på ZimaOS

Innan du försöker bygga en anpassad app bör du samla in information om enheterna på värddatorn:

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

Verifiera sedan om ZimaOS anpassade Docker-konfiguration kan representera alla krav som dokumenteras av ARM:

den optiska /dev/sr* enhet;
motsvarande /dev/sg* enhet;
nödvändiga behörigheter för värd och container;
beständiga volymer för konfiguration, loggar, musik och media;
privilegierat läge eller motsvarande funktioner om det krävs;
händelse-/udev-arbetsflödet på värddatorn som används för automatisk rippning.

Om ZimaOS inte kan exponera något av dessa krav genom sin aktuella applikationsmodell löser det inte rippningsfelet att ändra vanliga Docker-volymsökvägar.

Säkerhets- och tillförlitlighetsanteckningar

Privilegierade containrar får bred åtkomst till värddatorn. Använd endast betrodda avbildningar och förstå exponeringen.
Vidarebefordra inte orelaterade värdenheter till ARM.
Ge ARM skrivåtkomst endast till de kataloger som behövs.
Använd en särskild arbetskatalog med tillräckligt ledigt utrymme; optisk rippning och omkodning kan tillfälligt kräva betydande lagringsutrymme.
Säkerhetskopiera färdigt medieinnehåll separat från rippningsarbetsflödet.

Checklista för ARM på ZimaOS

Bekräfta att den optiska enheten visas på ZimaOS-värden.
Kör lsscsi -g och identifiera båda /dev/sr* och /dev/sg*.
Jämför funktionerna i ZimaOS anpassade appar med ARMs aktuella Docker-krav.
Anpassa ARM_UID/ARM_GID till skrivbara kataloger på värddatorn.
Kontrollera om privilegierat läge och integrering med värddatorns händelser är tillgängliga.
Utgå inte från att ett körande ARM-WebUI innebär att MakeMKV har korrekt åtkomst till enheten.
Om vidarebefordran av enheter fortfarande är opålitlig kan du använda en separat rippningsdator och lagra det färdiga resultatet på ZimaOS.

Vanliga frågor om Automatic Ripping Machine på ZimaOS

Kan ARM installeras på ZimaOS?

Det går att köra i en container, men den ursprungliga tråden bekräftade inte en fullt fungerande rippningskonfiguration på ZimaOS eftersom vidarebefordran av den optiska enheten och behörigheter var de hinder som kvarstod.

Varför säger ripprogrammet att skivan inte kan läsas?

En möjlig orsak är ofullständig vidarebefordran av enheter. I ARMs aktuella dokumentation står det att MakeMKV kan kräva både den optiska /dev/sr* enhet och motsvarande generiska SCSI-enhet /dev/sg* enhet.

Kräver ARM privilegierat läge?

Den aktuella Docker-dokumentationen för ARM inkluderar privilegierat läge i installations- och felsökningsanvisningarna för vissa konfigurationer. Huruvida varje installation behöver det beror på värddatorn och enhetsarbetsflödet.

Vilken lösning accepterades i den ursprungliga tråden?

Den ursprungliga författaren valde att installera ARM på en andra dator och flytta de rippade filerna till lagringen på ZimaOS-servern.