Limites da Automatic Ripping Machine no ZimaOS

A Automatic Ripping Machine (ARM) pode ser empacotada e iniciada como uma aplicação Docker, mas isso não significa que a extração de discos óticos funcione corretamente no ZimaOS. O tópico da IceWhale Community de janeiro de 2026 chegou exatamente a essa distinção: a ARM está contentorizada, mas uma extração fiável de CD/DVD/Blu-ray requer um acesso invulgarmente profundo à unidade ótica e à camada de dispositivos Linux do anfitrião.

O tópico não apresentou uma configuração da ARM no ZimaOS confirmadamente funcional. Um participante relatou que a ARM não funcionava corretamente e que outro extrator Docker produzia erros de disco ilegível. A recomendação prática da comunidade foi fazer a extração noutra máquina Linux e guardar os ficheiros concluídos no ZimaOS através de SMB ou NFS. A documentação atual da ARM apoia o diagnóstico técnico: a sua configuração Docker espera a passagem do dispositivo ótico, dispositivos genéricos SCSI, UID/GID do anfitrião correspondentes e, em algumas configurações, o modo privilegiado e a integração do udev do anfitrião.

Porque uma aplicação Docker normal não é suficiente para extrair discos

A maioria das aplicações NAS só precisa de portas de rede e volumes de dados. A extração ótica é diferente, porque software como o MakeMKV e a ARM precisa de comunicar diretamente com o hardware da unidade.

Os dispositivos óticos Linux típicos incluem:

/dev/sr0
/dev/sg1

O /dev/sr* o dispositivo expõe a unidade ótica, enquanto o correspondente /dev/sg* Pode ser necessário um dispositivo genérico SCSI para comandos de nível inferior. Se o contentor receber apenas uma montagem de pasta normal, não conseguirá executar essas operações.

Os sintomas relatados no tópico do ZimaOS

Um utilizador da comunidade relatou:

a ARM não funcionava corretamente;
outro extrator Docker só arrancava numa configuração restrita;
o syslog-ng encontrou problemas de socket/permissões;
a extração produzia erros de disco ilegível, mesmo quando se acreditava que o disco físico estava em boas condições.

Outra resposta explicou que estes sintomas eram compatíveis com acesso incompleto à unidade: /dev/sr0, passagem SCSI, eventos udev ou outras permissões ao nível do anfitrião.

A documentação atual da ARM confirma os requisitos de hardware

A documentação atual da ARM instrui os utilizadores a inspecionar os dispositivos óticos com:

lsscsi -g

Uma unidade pode aparecer, conceptualmente, como:

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

A ARM recomenda então passar ambos os dispositivos para o contentor:

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

Consulte a documentação da ARM para Docker.

A ARM também poderá precisar de acesso a contentores privilegiados

O guia atual da ARM para instalar o Docker a partir do código-fonte inclui:

--privileged

e a respetiva documentação de resolução de problemas indica que alguns utilizadores precisam do modo privilegiado para que a inserção de discos e a extração orientada por udev funcionem plenamente.

Esta é uma diferença importante em relação aos contentores comuns de servidores multimédia. O modo privilegiado concede a um contentor amplas capacidades sobre os dispositivos do anfitrião, pelo que não deve ser ativado de forma leviana numa imagem não confiável.

A automatização da inserção de discos depende do anfitrião

O ARM foi concebido para reagir automaticamente quando um disco é inserido. A documentação do Docker espera uma configuração da unidade no anfitrião e o comportamento do udev, para que a inserção possa desencadear o fluxo de extração.

O guia de resolução de problemas do ARM sugere verificar os registos do anfitrião quanto ao evento de inserção e confirma que um contentor pode estar saudável enquanto a extração automática continua a falhar se a integração do udev no anfitrião não estiver a funcionar.

Referência atual: Resolução de problemas do Docker do ARM.

Porque pode o MakeMKV falhar mesmo quando o ARM deteta a unidade

A documentação do ARM alerta especificamente para o facto de o MakeMKV poder não detetar ou ler uma unidade se apenas /dev/sr0 é transmitido e o dispositivo genérico SCSI correspondente é omitido.

Isto torna especialmente importante o sintoma de “disco ilegível” da discussão sobre o ZimaOS. Uma unidade ótica legível no anfitrião não prova que o contentor tenha todas as interfaces de dispositivo de que o MakeMKV necessita.

O ARM também requer permissões correspondentes no anfitrião

A documentação atual do ARM recomenda criar um arm utilizador/grupo no anfitrião e alinhar o:

ARM_UID
ARM_GID

com essa conta de anfitrião. Os diretórios de multimédia, configuração, música e registos têm de ser graváveis por essa identidade.

Se os IDs não coincidirem, o ARM pode falhar antes de o fluxo de extração chegar sequer à unidade ótica.

O que o tópico de origem confirma realmente sobre o ZimaOS

A discussão de origem não confirma que o ARM seja impossível no ZimaOS para sempre. Confirma que, em janeiro de 2026, os participantes não dispunham de uma configuração verificada que expusesse com êxito todos os privilégios necessários da unidade ótica.

Uma resposta considerava que a principal limitação era o nível de acesso ao hardware/dispositivo disponibilizado ao contentor. O autor original aceitou a solução prática de utilizar uma segunda máquina para a extração.

Não transforme esse resultado numa afirmação geral de que o Docker não consegue extrair discos ou de que o ZimaOS nunca poderá suportar o ARM.

A solução prática da comunidade

O plano final aceite pelo autor original foi:

Instale o ARM noutra máquina Linux com acesso direto à unidade ótica.
Extraia e transcodifique o disco nessa máquina.
Guarde ou mova os ficheiros concluídos para o armazenamento do ZimaOS.

O destino pode ser uma partilha SMB ou NFS montada, ou os ficheiros podem ser transferidos após a extração.

Isto mantém o ZimaOS focado no armazenamento e na disponibilização de conteúdos multimédia, enquanto a segunda máquina trata do hardware ótico de baixo nível.

A ARM suporta oficialmente fluxos de trabalho de saída com suporte de rede

A documentação Docker do ARM indica que os volumes de saída podem apontar para partilhas de rede, embora o desempenho dependa da rede e do comportamento da montagem.

Uma arquitetura comum é:

Unidade ótica
     ↓
Máquina Linux com ARM
     ↓
Armazenamento de trabalho temporário local
     ↓
Extração concluída
     ↓
Biblioteca multimédia SMB/NFS do ZimaOS

Utilizar armazenamento temporário local rápido para a fase de extração/transcodificação e transferir apenas o resultado concluído para o NAS pode reduzir problemas de rede e de bloqueios.

Se ainda quiser testar o ARM diretamente no ZimaOS

Antes de tentar criar uma aplicação personalizada, recolha as informações dos dispositivos do anfitrião:

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

Em seguida, verifique se a configuração Docker de aplicação personalizada do ZimaOS consegue representar todos os requisitos documentados pelo ARM:

o dispositivo ótico /dev/sr* dispositivo;
o correspondente /dev/sg* dispositivo;
permissões necessárias do anfitrião/contentor;
volumes persistentes de configuração, registos, música e conteúdos multimédia;
modo privilegiado ou capacidades equivalentes, se necessário;
o fluxo de eventos do anfitrião através de udev utilizado para a extração automática.

Se o ZimaOS não conseguir expor um desses requisitos através do seu modelo atual de aplicações, alterar os caminhos normais dos volumes Docker não resolverá a falha de extração.

Notas de segurança e fiabilidade

Os contentores privilegiados recebem acesso amplo ao anfitrião. Utilize apenas imagens de confiança e compreenda a exposição.
Não passe dispositivos do anfitrião não relacionados para o ARM.
Dê ao ARM acesso de escrita apenas aos diretórios de que necessita.
Utilize um diretório de trabalho dedicado com espaço livre suficiente; a extração ótica e a transcodificação podem exigir temporariamente uma quantidade considerável de armazenamento.
Faça cópias de segurança dos conteúdos multimédia concluídos, independentemente do fluxo de extração.

Lista de verificação do ARM no ZimaOS

Confirme que a unidade ótica aparece no anfitrião ZimaOS.
Execute lsscsi -g e identifique ambos /dev/sr* e /dev/sg*.
Compare as capacidades das aplicações personalizadas do ZimaOS com os requisitos atuais do Docker do ARM.
Alinhe ARM_UID/ARM_GID com diretórios do anfitrião onde seja possível escrever.
Verifique se o modo privilegiado e a integração com os eventos do anfitrião estão disponíveis.
Não assuma que uma WebUI do ARM em execução significa que o MakeMKV tem acesso correto à unidade.
Se a passagem do dispositivo continuar pouco fiável, utilize uma máquina de extração separada e armazene o resultado concluído no ZimaOS.

FAQ do Automatic Ripping Machine no ZimaOS

É possível instalar o ARM no ZimaOS?

Pode ser executado num contentor, mas o tópico de origem não confirmou uma configuração de extração totalmente funcional no ZimaOS, porque a passagem da unidade ótica e os privilégios eram o problema impeditivo.

Porque é que o ripper diz que o disco não pode ser lido?

Uma possível causa é a passagem incompleta do dispositivo. A documentação atual do ARM indica que o MakeMKV pode precisar tanto do dispositivo ótico /dev/sr* dispositivo e o dispositivo genérico SCSI correspondente /dev/sg* dispositivo.

O ARM requer o modo privilegiado?

A documentação atual do Docker do ARM inclui o modo privilegiado nas orientações de configuração e resolução de problemas para algumas configurações. A necessidade em cada instalação depende do anfitrião e do fluxo de trabalho do dispositivo.

Qual foi a solução aceite no tópico de origem?

O autor original optou por instalar o ARM numa segunda máquina e transferir os ficheiros extraídos para o armazenamento no servidor ZimaOS.