Automatic Ripping Machine (ARM) can be packaged and launched as a Docker application, but that does not mean optical-disc ripping will work correctly on ZimaOS. The January 2026 IceWhale Community thread reached that exact distinction: ARM itself is containerized, but reliable CD/DVD/Blu-ray ripping needs unusually deep access to the optical drive and host Linux device layer.
The thread did not produce a confirmed fully working ARM-on-ZimaOS configuration. One participant reported that ARM would not run correctly and that another Docker ripper produced unreadable-disc errors. The practical community recommendation was to rip on a second Linux machine and save the finished files to ZimaOS over SMB or NFS. Current ARM documentation supports the technical diagnosis: its Docker setup expects optical device passthrough, SCSI generic devices, matching host UID/GID, and in some configurations privileged mode and host udev integration.
Why a Normal Docker App Is Not Enough for Disc Ripping
Most NAS apps only need network ports and data volumes. Optical ripping is different because software such as MakeMKV and ARM needs to communicate directly with the drive hardware.
Typical Linux optical devices include:
/dev/sr0
/dev/sg1The /dev/sr* device exposes the optical drive, while the matching /dev/sg* SCSI generic device can be required for lower-level commands. If the container receives only a normal folder mount, it cannot perform those operations.
The Symptoms Reported in the ZimaOS Thread
A community user reported:
- ARM would not run successfully;
- another Docker ripper would start only in a restricted configuration;
- syslog-ng encountered socket/permission issues;
- ripping produced unreadable-disc errors even when the physical disc was believed to be good.
Another reply explained that these symptoms were consistent with incomplete access to /dev/sr0, SCSI passthrough, udev events, or other host-level permissions.
Current ARM Documentation Confirms the Hardware Requirements
Current ARM Docker documentation instructs users to inspect optical devices with:
lsscsi -gA drive may appear conceptually like:
cd/dvd ... /dev/sr0 /dev/sg1ARM then recommends passing both devices into the container:
--device="/dev/sr0:/dev/sr0"
--device="/dev/sg1:/dev/sg1"See the current ARM Docker documentation.
ARM May Also Need Privileged Container Access
ARM's current Docker-from-source guide includes:
--privilegedand its troubleshooting documentation says some users need privileged mode for disc insertion and udev-driven ripping to work fully.
This is a major difference from ordinary media-server containers. Privileged mode gives a container broad host-device capabilities, so it should not be enabled casually on an untrusted image.
Disc Insertion Automation Depends on the Host
ARM is designed to automatically react when a disc is inserted. Its Docker documentation expects host-side drive configuration and udev behavior so insertion can trigger the ripping workflow.
The ARM troubleshooting guide suggests checking host logs for the insertion event and confirms that a container can be healthy while automatic ripping still fails if the host udev integration is not working.
Current reference: ARM Docker Troubleshooting.
Why MakeMKV Can Fail Even When ARM Sees the Drive
ARM's documentation specifically warns that MakeMKV may fail to detect or read a drive if only /dev/sr0 is passed and the matching SCSI generic device is omitted.
That makes the “unreadable disc” symptom from the ZimaOS discussion especially important. A readable optical drive in the host does not prove that the container has all of the device interfaces MakeMKV needs.
ARM Also Requires Matching Host Permissions
Current ARM documentation recommends creating an arm user/group on the host and aligning the container's:
ARM_UID
ARM_GIDwith that host account. The media, config, music, and log directories must be writable by that identity.
If the IDs do not match, ARM can fail before the ripping workflow even reaches the optical drive.
What the Source Thread Actually Confirms About ZimaOS
The source discussion does not confirm that ARM is impossible on ZimaOS forever. It confirms that in January 2026 the participants did not have a verified configuration that exposed all of the required optical-drive privileges successfully.
One reply believed the main limitation was the level of hardware/device access available to the container. The original author accepted the practical workaround of using a second machine for ripping.
Do not convert that result into a blanket claim that Docker cannot rip discs or that ZimaOS can never support ARM.
The Community's Practical Workaround
The final plan accepted by the original author was:
- Install ARM on another Linux machine that has direct optical-drive access.
- Rip and transcode the disc there.
- Save or move the completed files to ZimaOS storage.
The destination can be a mounted SMB or NFS share, or files can be transferred after ripping.
This keeps ZimaOS focused on storage and media serving while the second machine handles the low-level optical hardware.
ARM Officially Supports Network-Backed Output Workflows
ARM's Docker documentation notes that output volumes can point to network shares, although performance depends on the network and mount behavior.
A common architecture is:
Optical drive
↓
ARM Linux machine
↓
Local temporary working storage
↓
Completed rip
↓
ZimaOS SMB/NFS media libraryUsing fast local temporary storage for the ripping/transcoding stage and moving only completed output to the NAS can reduce network and locking problems.
If You Still Want to Test ARM Directly on ZimaOS
Before trying to build a custom app, collect the host device information:
lsscsi -g
ls -l /dev/sr*
ls -l /dev/sg*Then verify whether the ZimaOS custom Docker configuration can represent all of the requirements documented by ARM:
- the optical
/dev/sr*device; - the matching
/dev/sg*device; - required host/container permissions;
- persistent config, logs, music, and media volumes;
- privileged mode or equivalent capabilities if required;
- the host-side event/udev workflow used for automatic ripping.
If ZimaOS cannot expose one of those requirements through its current application model, changing normal Docker volume paths will not solve the ripping failure.
Security and Reliability Notes
- Privileged containers receive broad host access. Use only trusted images and understand the exposure.
- Do not pass unrelated host devices into ARM.
- Give ARM write access only to the directories it needs.
- Use a dedicated working directory with enough free space; optical ripping and transcoding can temporarily require substantial storage.
- Back up completed media independently of the ripping workflow.
ARM on ZimaOS Checklist
- Confirm the optical drive appears on the ZimaOS host.
- Run
lsscsi -gand identify both/dev/sr*and/dev/sg*. - Compare the ZimaOS custom-app capabilities with ARM's current Docker requirements.
- Align ARM_UID/ARM_GID with writable host directories.
- Verify whether privileged mode and host event integration are available.
- Do not assume that a running ARM WebUI means MakeMKV has correct drive access.
- If device passthrough remains unreliable, use a separate ripping machine and store completed output on ZimaOS.
Automatic Ripping Machine on ZimaOS FAQ
Can ARM be installed on ZimaOS?
It can be containerized, but the source thread did not confirm a fully working ZimaOS ripping setup because optical-drive passthrough and privileges were the blocking issue.
Why does the ripper say the disc is unreadable?
One possible cause is incomplete device passthrough. ARM's current documentation says MakeMKV may require both the optical /dev/sr* device and the matching SCSI generic /dev/sg* device.
Does ARM require privileged mode?
Current ARM Docker documentation includes privileged mode in its setup and troubleshooting guidance for some configurations. Whether every installation needs it depends on the host and device workflow.
What was the source thread's accepted solution?
The original author chose to install ARM on a second machine and move the ripped files to storage on the ZimaOS server.
