Limiti di Automatic Ripping Machine su ZimaOS

Automatic Ripping Machine (ARM) può essere impacchettato e avviato come applicazione Docker, ma ciò non significa che il ripping di dischi ottici funzionerà correttamente su ZimaOS. La discussione della community IceWhale del gennaio 2026 ha evidenziato proprio questa distinzione: ARM è containerizzato, ma un ripping affidabile di CD/DVD/Blu-ray richiede un accesso insolitamente profondo all’unità ottica e al livello dei dispositivi Linux dell’host.

La discussione non ha prodotto una configurazione ARM su ZimaOS confermata come pienamente funzionante. Un partecipante ha riferito che ARM non funzionava correttamente e che un altro ripper Docker produceva errori di disco illeggibile. La raccomandazione pratica della community era eseguire il ripping su una seconda macchina Linux e salvare i file completati su ZimaOS tramite SMB o NFS. L’attuale documentazione di ARM supporta la diagnosi tecnica: la sua configurazione Docker prevede il passthrough dei dispositivi ottici, dispositivi SCSI generici, UID/GID dell’host corrispondenti e, in alcune configurazioni, la modalità privilegiata e l’integrazione con udev dell’host.

Perché una normale app Docker non basta per il ripping dei dischi

La maggior parte delle app NAS necessita solo di porte di rete e volumi dati. Il ripping ottico è diverso, perché software come MakeMKV e ARM deve comunicare direttamente con l’hardware dell’unità.

I dispositivi ottici Linux tipici includono:

/dev/sr0
/dev/sg1

Il /dev/sr* il dispositivo espone l’unità ottica, mentre il corrispondente /dev/sg* Il dispositivo SCSI generico può essere necessario per i comandi di livello più basso. Se il container riceve solo il montaggio di una normale cartella, non può eseguire tali operazioni.

I sintomi segnalati nella discussione su ZimaOS

Un utente della community ha riferito:

ARM non funzionava correttamente;
un altro ripper Docker si avviava solo in una configurazione limitata;
syslog-ng riscontrava problemi di socket e autorizzazioni;
il ripping produceva errori di disco illeggibile anche quando si riteneva che il disco fisico fosse integro.

Un’altra risposta spiegava che questi sintomi erano compatibili con un accesso incompleto a /dev/sr0, il passthrough SCSI, gli eventi udev o altri permessi a livello di host.

L’attuale documentazione di ARM conferma i requisiti hardware

L’attuale documentazione Docker di ARM indica agli utenti di verificare i dispositivi ottici con:

lsscsi -g

Un’unità potrebbe apparire, ad esempio, così:

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

ARM consiglia quindi di passare entrambi i dispositivi al container:

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

Consulta la documentazione Docker di ARM.

ARM potrebbe inoltre richiedere l’accesso a un container privilegiato

L’attuale guida di ARM per la compilazione di Docker dai sorgenti include:

--privileged

e la relativa documentazione per la risoluzione dei problemi indica che alcuni utenti necessitano della modalità privilegiata affinché l’inserimento dei dischi e il ripping gestito da udev funzionino correttamente.

Questa è una differenza importante rispetto ai normali container per server multimediali. La modalità privilegiata offre a un container ampie capacità sui dispositivi dell'host, quindi non dovrebbe essere abilitata con leggerezza su un'immagine non considerata attendibile.

L'automazione dell'inserimento dei dischi dipende dall'host

ARM è progettato per reagire automaticamente all'inserimento di un disco. La documentazione Docker prevede la configurazione dell'unità e il comportamento di udev sul lato host, affinché l'inserimento possa avviare il flusso di ripping.

La guida alla risoluzione dei problemi di ARM suggerisce di controllare i log dell'host per l'evento di inserimento e conferma che un container può essere operativo mentre il ripping automatico continua a non funzionare se l'integrazione udev dell'host non funziona.

Riferimento attuale: Risoluzione dei problemi di ARM Docker.

Perché MakeMKV può non funzionare anche quando ARM rileva l'unità

La documentazione di ARM avverte specificamente che MakeMKV potrebbe non riuscire a rilevare o leggere un'unità se viene passato solo /dev/sr0 viene passato e il dispositivo generico SCSI corrispondente viene omesso.

Questo rende particolarmente importante il sintomo del “disco illeggibile” emerso nella discussione su ZimaOS. Un'unità ottica leggibile sull'host non dimostra che il container disponga di tutte le interfacce del dispositivo necessarie a MakeMKV.

ARM richiede anche permessi host corrispondenti

La documentazione attuale di ARM consiglia di creare un arm utente/gruppo sull'host e allineando i valori del container:

ARM_UID
ARM_GID

con quell'account host. Le directory dei contenuti multimediali, di configurazione, della musica e dei log devono essere scrivibili da quell'identità.

Se gli ID non corrispondono, ARM può non riuscire prima ancora che il flusso di ripping raggiunga l'unità ottica.

Cosa conferma realmente il thread originale su ZimaOS

La discussione di origine non conferma che ARM sia impossibile su ZimaOS per sempre. Conferma che, a gennaio 2026, i partecipanti non disponevano di una configurazione verificata che esponesse correttamente tutti i privilegi richiesti dall'unità ottica.

Una risposta riteneva che la limitazione principale fosse il livello di accesso all'hardware e ai dispositivi disponibile per il container. L'autore originale ha accettato la soluzione pratica di utilizzare una seconda macchina per il ripping.

Non trasformare questo risultato in un'affermazione generale secondo cui Docker non può eseguire il ripping dei dischi o ZimaOS non potrà mai supportare ARM.

La soluzione pratica della community

Il piano finale accettato dall'autore originale era:

Installa ARM su un'altra macchina Linux che abbia accesso diretto all'unità ottica.
Esegui il ripping e la transcodifica del disco su quella macchina.
Salva o sposta i file completati nell'archiviazione di ZimaOS.

La destinazione può essere una condivisione SMB o NFS montata, oppure i file possono essere trasferiti dopo il ripping.

In questo modo ZimaOS rimane focalizzato sull'archiviazione e sulla distribuzione multimediale, mentre la seconda macchina gestisce l'hardware ottico di basso livello.

ARM supporta ufficialmente i flussi di lavoro con output su rete

La documentazione Docker di ARM indica che i volumi di output possono puntare a condivisioni di rete, anche se le prestazioni dipendono dalla rete e dal comportamento del montaggio.

Un’architettura comune è:

Unità ottica
     ↓
Macchina Linux ARM
     ↓
Spazio di lavoro temporaneo locale
     ↓
Estrazione completata
     ↓
Libreria multimediale SMB/NFS di ZimaOS

Usare spazio di archiviazione temporaneo locale e veloce per la fase di estrazione/transcodifica e spostare sulla NAS solo l’output completato può ridurre i problemi di rete e di blocco.

Se vuoi comunque testare ARM direttamente su ZimaOS

Prima di provare a creare un’app personalizzata, raccogli le informazioni sui dispositivi dell’host:

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

Poi verifica se la configurazione Docker dell’app personalizzata di ZimaOS è in grado di rappresentare tutti i requisiti documentati da ARM:

l’unità ottica /dev/sr* dispositivo;
il corrispondente /dev/sg* dispositivo;
permessi host/container richiesti;
volumi persistenti per configurazione, log, musica e contenuti multimediali;
modalità privilegiata o funzionalità equivalenti, se richieste;
il flusso di lavoro degli eventi/udev sull’host usato per l’estrazione automatica.

Se ZimaOS non può esporre uno di questi requisiti tramite il modello applicativo attuale, modificare i normali percorsi dei volumi Docker non risolverà il problema di estrazione.

Note sulla sicurezza e sull’affidabilità

I container privilegiati ricevono un ampio accesso all’host. Usa solo immagini affidabili e comprendi l’esposizione.
Non passare ad ARM dispositivi host non correlati.
Concedi ad ARM l’accesso in scrittura solo alle directory necessarie.
Usa una directory di lavoro dedicata con spazio libero sufficiente; l’estrazione e la transcodifica ottiche possono richiedere temporaneamente una quantità considerevole di spazio di archiviazione.
Esegui il backup dei contenuti multimediali completati indipendentemente dal flusso di estrazione.

Checklist di ARM su ZimaOS

Conferma che l’unità ottica sia visibile sull’host ZimaOS.
Esegui lsscsi -g e identifica entrambi /dev/sr* e /dev/sg*.
Confronta le funzionalità delle app personalizzate di ZimaOS con i requisiti Docker attuali di ARM.
Allinea ARM_UID/ARM_GID con le directory host scrivibili.
Verifica se la modalità privilegiata e l’integrazione degli eventi dell’host sono disponibili.
Non dare per scontato che un’interfaccia Web ARM funzionante significhi che MakeMKV abbia accesso corretto all’unità.
Se il passthrough del dispositivo rimane inaffidabile, usa una macchina separata per l’estrazione e archivia l’output completato su ZimaOS.

Domande frequenti su Automatic Ripping Machine su ZimaOS

È possibile installare ARM su ZimaOS?

Può essere eseguito in un container, ma la discussione originale non ha confermato una configurazione di estrazione ZimaOS pienamente funzionante, perché il passthrough dell’unità ottica e i privilegi erano il problema bloccante.

Perché il programma di estrazione segnala che il disco non è leggibile?

Una possibile causa è il passthrough incompleto del dispositivo. La documentazione attuale di ARM indica che MakeMKV potrebbe richiedere sia il dispositivo ottico /dev/sr* dispositivo e il corrispondente dispositivo generico SCSI /dev/sg* dispositivo.

ARM richiede la modalità privilegiata?

La documentazione attuale di ARM per Docker include la modalità privilegiata nelle indicazioni di configurazione e risoluzione dei problemi per alcune configurazioni. La necessità per ogni installazione dipende dall’host e dal flusso di lavoro del dispositivo.

Qual è stata la soluzione accettata nella discussione originale?

L’autore originale ha scelto di installare ARM su una seconda macchina e di spostare i file estratti nell’archiviazione del server ZimaOS.