Automatic Ripping Machine(ARM)은 Docker 애플리케이션으로 패키징하고 실행할 수 있지만, 그렇다고 해서 ZimaOS에서 광학 디스크 리핑이 올바르게 작동한다는 의미는 아닙니다. 2026년 1월 IceWhale Community 스레드에서는 바로 이러한 차이가 확인되었습니다. ARM 자체는 컨테이너화되어 있지만 안정적인 CD/DVD/Blu-ray 리핑을 위해서는 광학 드라이브와 호스트 Linux 장치 계층에 훨씬 더 깊은 수준의 액세스가 필요합니다.
해당 스레드에서는 ARM을 ZimaOS에서 완전히 작동하는 구성으로 실행하는 방법이 확인되지 않았습니다. 한 참가자는 ARM이 제대로 실행되지 않았고 다른 Docker 리퍼에서는 읽을 수 없는 디스크 오류가 발생했다고 보고했습니다. 실질적인 커뮤니티 권장 사항은 두 번째 Linux 컴퓨터에서 리핑한 후 완성된 파일을 SMB 또는 NFS를 통해 ZimaOS에 저장하는 것이었습니다. 최신 ARM 문서는 기술적 진단을 뒷받침합니다. ARM의 Docker 설정에는 광학 장치 패스스루, SCSI 일반 장치, 일치하는 호스트 UID/GID가 필요하며, 일부 구성에서는 권한 있는 모드와 호스트 udev 통합도 필요합니다.
일반 Docker 앱만으로는 디스크 리핑에 충분하지 않은 이유
대부분의 NAS 앱에는 네트워크 포트와 데이터 볼륨만 필요합니다. 하지만 광학 디스크 리핑은 MakeMKV 및 ARM과 같은 소프트웨어가 드라이브 하드웨어와 직접 통신해야 하므로 다릅니다.
일반적인 Linux 광학 장치에는 다음이 포함됩니다.
/dev/sr0
/dev/sg1다음은 /dev/sr* 장치는 광학 드라이브를 노출하며, 이에 대응하는 /dev/sg* 하위 수준 명령을 실행하려면 SCSI 일반 장치가 필요할 수 있습니다. 컨테이너에 일반 폴더 마운트만 전달된 경우 이러한 작업을 수행할 수 없습니다.
ZimaOS 스레드에서 보고된 증상
한 커뮤니티 사용자는 다음과 같이 보고했습니다.
- ARM은 정상적으로 실행되지 않았습니다.
- 또 다른 Docker 리퍼는 제한된 구성에서만 시작되었습니다.
- syslog-ng에서 소켓 및 권한 문제가 발생했습니다.
- 리핑 과정에서 물리 디스크가 정상이라고 판단되었는데도 읽을 수 없는 디스크 오류가 발생했습니다.
또 다른 답변에서는 이러한 증상이 액세스 권한이 충분하지 않을 때 나타나는 현상과 일치한다고 설명했습니다. /dev/sr0, SCSI 패스스루, udev 이벤트 또는 기타 호스트 수준 권한이 필요할 수 있습니다.
최신 ARM 문서에서 하드웨어 요구 사항을 확인합니다
현재 ARM Docker 문서에서는 다음 명령으로 광학 장치를 확인하도록 안내합니다.
lsscsi -g드라이브는 개념적으로 다음과 같이 표시될 수 있습니다.
CD/DVD ... /dev/sr0 /dev/sg1ARM은 이어서 두 장치를 모두 컨테이너에 전달할 것을 권장합니다.
--device="/dev/sr0:/dev/sr0"
--device="/dev/sg1:/dev/sg1"최신 ARM Docker 문서를 참조하세요.
ARM에는 권한 있는 컨테이너 액세스가 필요할 수도 있습니다
ARM의 최신 소스 빌드 Docker 가이드에는 다음 내용이 포함되어 있습니다.
--privileged그리고 해당 문제 해결 문서에서는 디스크 삽입 및 udev 기반 리핑이 완전히 작동하려면 일부 사용자가 권한 있는 모드를 사용해야 한다고 설명합니다.
이는 일반적인 미디어 서버 컨테이너와 크게 다른 점입니다. 권한 모드는 컨테이너에 광범위한 호스트 장치 권한을 부여하므로, 신뢰할 수 없는 이미지에 함부로 활성화해서는 안 됩니다.
디스크 삽입 자동화는 호스트에 따라 달라집니다.
ARM은 디스크가 삽입될 때 자동으로 반응하도록 설계되었습니다. ARM의 Docker 문서에서는 디스크 삽입이 리핑 워크플로를 트리거할 수 있도록 호스트 측 드라이브 구성과 udev 동작을 요구합니다.
ARM 문제 해결 가이드에서는 디스크 삽입 이벤트에 대한 호스트 로그를 확인할 것을 제안하며, 호스트 udev 통합이 제대로 작동하지 않으면 컨테이너가 정상 상태여도 자동 리핑이 실패할 수 있음을 확인합니다.
현재 참고 자료: ARM Docker 문제 해결.
ARM이 드라이브를 감지하는데도 MakeMKV가 실패할 수 있는 이유
ARM 문서에서는 특히 다음 항목만 전달하면 MakeMKV가 드라이브를 감지하거나 읽지 못할 수 있다고 경고합니다. /dev/sr0 전달되지만 일치하는 SCSI 일반 장치는 제외된 경우
이 때문에 ZimaOS 토론에서 나온 “읽을 수 없는 디스크” 증상이 특히 중요합니다. 호스트에서 광학 드라이브를 읽을 수 있다고 해서 컨테이너에 MakeMKV에 필요한 모든 장치 인터페이스가 있다는 의미는 아닙니다.
ARM에는 일치하는 호스트 권한도 필요
현재 ARM 문서에서는 다음 항목을 생성할 것을 권장합니다. arm 호스트의 사용자/그룹과 컨테이너의 다음 항목을 일치시키는 작업:
ARM_UID
ARM_GID해당 호스트 계정으로. 미디어, 구성, 음악 및 로그 디렉터리는 해당 ID가 쓸 수 있어야 합니다.
ID가 일치하지 않으면 광학 드라이브에 도달하기도 전에 ARM이 실패할 수 있습니다.
원문 스레드가 ZimaOS에 관해 실제로 확인하는 내용
원문 토론은 ARM이 ZimaOS에서 영원히 불가능하다는 것을확인하지 않습니다. 토론 참여자들이 2026년 1월에 필요한 모든 광학 드라이브 권한을 성공적으로 노출하는 검증된 구성을 확보하지 못했다는 점을 확인할 뿐입니다.
한 답변에서는 주요 제한 사항이 컨테이너에 제공되는 하드웨어/장치 액세스 수준이라고 보았습니다. 원 작성자는 리핑에 두 번째 컴퓨터를 사용하는 실용적인 해결 방법을 수락했습니다.
이 결과를 Docker가 디스크를 리핑할 수 없다거나 ZimaOS가 ARM을 영원히 지원할 수 없다는 포괄적인 주장으로 확대 해석해서는 안 됩니다.
커뮤니티의 실용적인 해결 방법
원 작성자가 수락한 최종 계획은 다음과 같습니다.
- 광학 드라이브에 직접 액세스할 수 있는 다른 Linux 컴퓨터에 ARM을 설치합니다.
- 그곳에서 디스크를 리핑하고 트랜스코딩합니다.
- 완료된 파일을 ZimaOS 저장소에 저장하거나 이동합니다.
대상은 마운트된 SMB 또는 NFS 공유일 수 있으며, 리핑 후 파일을 전송할 수도 있습니다.
이렇게 하면 ZimaOS는 저장소와 미디어 제공에 집중하고, 두 번째 컴퓨터가 저수준 광학 하드웨어를 처리할 수 있습니다.
ARM, 네트워크 기반 출력 워크플로를 공식 지원
ARM의 Docker 문서에는 출력 볼륨을 네트워크 공유로 지정할 수 있다고 나와 있지만, 성능은 네트워크와 마운트 동작에 따라 달라집니다.
일반적인 아키텍처는 다음과 같습니다.
광학 드라이브
↓
ARM Linux 머신
↓
로컬 임시 작업 스토리지
↓
완료된 리핑 파일
↓
ZimaOS SMB/NFS 미디어 라이브러리리핑/트랜스코딩 단계에 빠른 로컬 임시 스토리지를 사용하고 완료된 출력물만 NAS로 옮기면 네트워크 및 잠금 문제를 줄일 수 있습니다.
그래도 ZimaOS에서 ARM을 직접 테스트하려는 경우
사용자 지정 앱을 빌드하기 전에 호스트 장치 정보를 수집하세요.
lsscsi -g
ls -l /dev/sr*
ls -l /dev/sg*그런 다음 ZimaOS 사용자 지정 Docker 구성이 ARM에 문서화된 모든 요구 사항을 표현할 수 있는지 확인하세요.
- 광학
/dev/sr*장치. - 해당
/dev/sg*장치. - 필요한 호스트/컨테이너 권한;
- 영구 구성, 로그, 음악 및 미디어 볼륨;
- 필요한 경우 권한 모드 또는 이에 상응하는 기능;
- 자동 리핑에 사용되는 호스트 측 이벤트/udev 워크플로.
ZimaOS가 현재 애플리케이션 모델을 통해 이러한 요구 사항 중 하나라도 노출할 수 없다면 일반 Docker 볼륨 경로를 변경해도 리핑 실패가 해결되지 않습니다.
보안 및 안정성 참고 사항
- 권한 컨테이너는 호스트에 광범위하게 액세스할 수 있습니다. 신뢰할 수 있는 이미지만 사용하고 노출 범위를 이해하세요.
- 관련 없는 호스트 장치를 ARM에 전달하지 마세요.
- ARM에 필요한 디렉터리에만 쓰기 권한을 부여하세요.
- 충분한 여유 공간이 있는 전용 작업 디렉터리를 사용하세요. 광학 디스크 리핑 및 트랜스코딩에는 일시적으로 상당한 저장 공간이 필요할 수 있습니다.
- 완료된 미디어는 리핑 워크플로와 별도로 백업하세요.
ZimaOS에서 ARM 사용 체크리스트
- 광학 드라이브가 ZimaOS 호스트에 표시되는지 확인하세요.
- 실행
lsscsi -g및 둘 다 식별합니다/dev/sr*및/dev/sg*. - ZimaOS 사용자 지정 앱의 기능을 ARM의 현재 Docker 요구 사항과 비교하세요.
- ARM_UID/ARM_GID를 쓰기 가능한 호스트 디렉터리에 맞추세요.
- 권한 모드와 호스트 이벤트 통합을 사용할 수 있는지 확인하세요.
- 실행 중인 ARM WebUI가 MakeMKV에 올바른 드라이브 액세스 권한이 있다는 의미라고 단정하지 마세요.
- 장치 패스스루가 계속 불안정하다면 별도의 리핑 머신을 사용하고 완료된 출력물을 ZimaOS에 저장하세요.
ZimaOS의 Automatic Ripping Machine FAQ
ZimaOS에 ARM을 설치할 수 있나요?
컨테이너화할 수는 있지만, 원본 스레드에서는 광학 드라이브 패스스루와 권한이 문제였기 때문에 ZimaOS에서 완전히 작동하는 리핑 설정이 확인되지 않았습니다.
왜 리퍼가 디스크를 읽을 수 없다고 표시하나요?
가능한 원인 중 하나는 장치 패스스루가 불완전한 것입니다. ARM의 현재 문서에 따르면 MakeMKV에는 광학 장치와 /dev/sr* 장치와 해당 SCSI 일반 /dev/sg* 장치.
ARM에 권한 모드가 필요한가요?
현재 ARM Docker 문서에는 일부 구성에 대한 설정 및 문제 해결 지침에 권한 모드가 포함되어 있습니다. 모든 설치에 권한 모드가 필요한지는 호스트와 장치 워크플로에 따라 다릅니다.
원본 스레드에서 채택된 해결 방법은 무엇이었나요?
원 저자는 두 번째 컴퓨터에 ARM을 설치한 다음, 리핑한 파일을 ZimaOS 서버의 스토리지로 옮기는 방식을 선택했습니다.
