리더기는 연결되었지만 컨테이너 사용자가 열 수 없었습니다
ZimaOS 호스트는 FTDI 리더기를 /dev/ttyUSB0으로 생성했고, 해당 장치를 LinuxServer OSCam 컨테이너에 전달했습니다. 그러나 OSCam에는 여전히 errno=13 Permission denied가 기록되었습니다.
호스트에서는 문자 장치가 root:dialout 소유이며 권한 모드가 660으로 표시되었습니다. 컨테이너는 PUID=1000 및 PGID=1000으로 구성되어 있었기 때문에, 컨테이너의 애플리케이션 사용자는 장치를 열 수 있는 소유자 또는 dialout 그룹과 일치하지 않았습니다.
컨테이너 ID를 변경하자 FTDI 액세스가 해결되었습니다
처음 시도해 볼 방법으로 OSCam 컨테이너를 다음과 같이 설정해 root로 실행하는 방법이 제안되었습니다.
PUID=0
PGID=0기존 매핑은 그대로 유지되었습니다.
devices:
- /dev/ttyUSB0:/dev/ttyUSB0작성자는 이 첫 번째 방법만으로 충분했으며, 이후 FTDI 리더기가 정상적으로 작동했다고 확인했습니다. 컨테이너를 root로 실행하고 privileged 모드를 활성화하면 광범위한 액세스 권한이 부여되므로, 이 결과는 최소 권한을 적용한 이상적인 해결책이라기보다 보안 범위가 더 넓은 커뮤니티의 기능적 해결 방법으로 보아야 합니다.
그룹 매핑은 더 제한적인 대안입니다
답변에서는 컨테이너 프로세스를 호스트의 dialout 그룹에 추가하는 방법도 설명했습니다. 이 방법을 사용하면 root가 아닌 애플리케이션 ID를 유지할 수 있지만, 해당 스레드에는 테스트를 거친 그룹 추가 설정이 제시되지 않았고 이 호스트의 dialout GID 숫자도 확인되지 않았습니다.
권한을 변경하기 전에 lsusb에서 FTDI 장치를 인식하는지, 그리고 /dev/ttyUSB0이 존재하는지 확인하세요. 장치 노드가 없다면 문제는 컨테이너 소유권이 아니라 드라이버 감지 또는 재연결 동작과 관련된 것입니다.
이후 발생한 CCcam 시간 초과는 다른 문제였습니다
USB 액세스가 작동한 후 작성자는 CCcam 연결 시간 초과를 겪었습니다. 답변에서는 브리지 네트워킹과 호스트 네트워킹, 라우팅, 서브넷, 방화벽 규칙, 원격 서비스가 예상 주소에서 수신 대기 중인지 여부를 조사했습니다. 한때 클라이언트는 서버에 ping을 보내지도, 서버의 TCP 포트에 연결하지도 못했습니다.
이후 작성자는 LinuxServer OSCam 컨테이너 이미지를 업데이트하자 남아 있던 문제가 해결되었다고 보고했습니다. 문제가 발생한 이미지 태그와 해결된 이미지 태그가 정확히 기록되어 있지 않으므로, 이 스레드만으로는 구체적인 버전 경계를 확인할 수 없습니다.
FAQ
privileged 모드가 ttyUSB0 문제를 자동으로 해결하지 못한 이유는 무엇인가요?
문제의 원인은 컨테이너 내부 프로세스의 사용자 ID에 초점이 맞춰졌습니다. 장치가 root 및 dialout 액세스만 허용하는 동안에도 프로세스는 UID와 GID 1000으로 실행되고 있었습니다.
작성자가 FTDI 리더기에 대해 확인한 변경 사항은 무엇인가요?
PUID와 PGID를 0으로 변경했고, 처음 제안된 방법이 작동한다고 확인했습니다.
이후 발생한 네트워크 시간 초과가 USB 권한 때문에 발생했나요?
아니요. FTDI 문제는 이미 해결된 상태였습니다. 이후의 문제는 네트워크 연결성 또는 컨테이너 이미지와 관련된 것이었으며, 업데이트 후 정상적으로 작동한다고 보고되었습니다.
