Automatic Ripping Machine on Zimaos?

Insight & Feedback
1

Hello all, I was wondering if ARM ( Automatic Ripping Machine ) could be installed on Zimaos.?

1 Like
2

This and or rix1337’s docker ripper. Neither of their docker containers run in privileged mode. It has something to do with syslog-ng not having permissions to create a socket. Doesn’t matter if you run as root.

ARM will not run at all, whereas docker ripper will in non privileged mode only. Unfortunately, you will get unreadable disc errors due to the non privileged issue.

The lack of native disk ripping support really holds this NAS software back. ZimaOS is fantastic otherwise. In fact, I’m setting up a box for my parents on a spare pc so they can flip through their old photos, and backup their desktops. I myself use Unraid. Although a little more complicated, their AppStore has bases better covered. To be fair, unraid is a more mature product, with a larger user base. Unfortunately, lack of disk ripping is a deal breaker for me. I’m sure this will be sorted down the line. When it does, I’ll take another look at ZimaOS for my personal use.

Consider posting on ZimaOS subreddit, bigbear support forums, and NASCompares to generate interest and possible workarounds.

Good luck!

1 Like
3

Yes, ARM (Automatic Ripping Machine) can be installed on ZimaOS as a Docker app, but the real problem is hardware access to the optical drive.

I believe what you’re seeing is expected: ripping containers often need access to things like /dev/sr0, SCSI passthrough, udev events, and sometimes extra permissions. If the container can’t properly talk to the drive at a low level, you’ll get symptoms like:

  • ARM not starting correctly
  • syslog-ng socket/permission errors
  • “unreadable disc” / read errors even when the disc is fine
  • container works only in non-privileged mode but ripping fails

What I suggest (best practical path on ZimaOS)

  • Run the ripper container with full device passthrough (not just volumes)
  • Map /dev/sr0 and (if required) /dev/sg*
  • Ensure the container has the required permissions/capabilities (some rippers really do need more than standard mode)

If ZimaOS blocks or limits the needed privileges (even when “privileged” is enabled), then I suggest the most reliable workaround for now is:

Rip on another machine (PC / VM / small Linux box) > then store the output into ZimaOS via SMB/NFS.

That keeps ZimaOS doing what it does best (storage + apps) without fighting low-level optical drive access.

Big picture

I agree the lack of “native ripping” support is a gap, but I believe it’s not because ZimaOS is weak, it’s because optical ripping requires deep device integration, and that’s always messy inside containers.

If you want to help push it forward, I suggest opening a feature request with logs and exact errors so IceWhale can reproduce it.

1 Like
4

Thank you for your feed back I have a second Machine that i will install arm on and move the riped file to the storage on the server ..

once again thank you