リーダーは認識されていたが、コンテナユーザーは開けなかった
ZimaOSホストはFTDIリーダーを/dev/ttyUSB0として作成し、そのデバイスをLinuxServer OSCamコンテナに渡していました。それでもOSCamにはerrno=13 Permission deniedと記録されました。
ホストでは、キャラクターデバイスの所有者とグループがroot:dialoutで、権限モードは660でした。コンテナはPUID=1000およびPGID=1000で設定されていたため、アプリケーションユーザーが、デバイスを開く権限を持つ所有者またはdialoutグループと一致していませんでした。
コンテナの実行ユーザーを変更してFTDIへのアクセスを解決
最初のテストとして、次の設定でOSCamコンテナをrootとして実行することが提案されました。
PUID=0
PGID=0既存のマッピングはそのまま維持しました。
devices:
- /dev/ttyUSB0:/dev/ttyUSB0投稿者は、この最初の方法だけで十分であり、その後FTDIリーダーが動作したことを確認しました。コンテナをrootとして実行し、privilegedモードを有効にすると広範なアクセス権が付与されるため、この結果は機能するコミュニティでの解決策として扱うべきであり、最小権限の理想的な構成ではありません。
グループマッピングは、より限定的な代替策
返信では、コンテナプロセスをホストのdialoutグループに追加する方法も説明されました。この方法なら、root以外のアプリケーションユーザーを維持できます。ただし、スレッドにはテスト済みのグループ追加設定や、このホスト上のdialoutの数値GIDの確認結果は記載されていません。
権限を変更する前に、lsusbでFTDIデバイスが認識され、/dev/ttyUSB0が存在することを確認してください。デバイスノードが存在しない場合、問題はコンテナの所有権ではなく、ドライバーの検出または再接続時の動作にあります。
後から発生したCCcamのタイムアウトは別の問題
USBアクセスが機能した後、投稿者はCCcam接続のタイムアウトに遭遇しました。返信では、ブリッジネットワークとホストネットワークの違い、ルーティング、サブネット、ファイアウォールルール、リモートサービスが想定アドレスで待ち受けているかどうかが調査されました。ある時点では、クライアントからサーバーへのpingも、TCPポートへの接続もできませんでした。
その後、投稿者はLinuxServer OSCamコンテナイメージを更新したところ、残っていた問題が解決したと報告しました。問題のあったイメージタグと修正後のイメージタグは記録されていないため、正確なバージョンの境界は特定できません。
FAQ
なぜprivilegedモードだけではttyUSB0が自動的に使えるようにならなかったのですか？
動作時の診断では、コンテナ内のプロセスユーザーが重視されました。プロセスはUIDとGID 1000で実行されていましたが、デバイスへのアクセスが許可されていたのはrootとdialoutグループでした。
投稿者がFTDIリーダーについて確認した変更は何ですか？
PUIDとPGIDを0に変更し、最初に提案された方法で動作したことを確認しました。
後から発生したネットワークタイムアウトは、USB権限が原因でしたか？
いいえ。FTDIの問題はすでに解決していました。後から発生した問題はネットワーク到達性またはコンテナイメージに関するもので、更新後に動作したと報告されています。
