結論：chmod 777でZimaOSのマウントルートを「修正」しない
1.6.2 Beta 2では、新しくマウントしたBtrfsボリュームがroot:rootおよび755として表示され、通常のSSHユーザーが/media/<volume>のルートに直接書き込めなくなりました。これはベータ版で実際に確認された現象です。ただし、それだけで現行リリースに問題があるとは限らず、マウントルートの権限を再帰的に緩める回避策は危険です。
ベータ版では複数のストレージセキュリティ経路が変更された
関連する1.6.2 Beta 2の報告では、新しいセキュリティポリシーによってアプリデータの移行がブロックされました。IceWhaleは、この特定の移行失敗を修正予定の既知の問題として認めています。その後、安定版1.6.2では、より広範なセキュリティ強化とストレージ修正が導入されました。つまり、ベータ期間には意図的なセキュリティ変更と、少なくとも1件のリグレッションの両方が存在していたことは明らかです。
ZimaOS 1.6.xの変更概要は、当時の状況を理解するうえで役立つ資料です。
現在の公開ドキュメントは、すべてのマウントルートへの非root書き込みアクセスを保証していない
現在のZimaOSでは、ストレージはFiles、SMB共有、Dockerパスで使用される管理対象サービスとして扱われます。サポートされているユーザーワークフローは、フォルダーや共有を作成し、アプリケーションを適切なパスに割り当てることです。マウントしたすべてのディスクのルートに、任意のシェル操作で書き込むことを前提にはしていません。
現在のZimaOSストレージガイドと、ZimaOSのアプリパスおよび移行ガイドは、ベータ版のファイルシステムモード単独よりも、現在の状況を確認するための適切な資料です。
スクリプトに書き込み権限が必要な場合は、専用ディレクトリを与える
sudo mkdir -p /media/YourVolume/automation
sudo chown YOUR_USER:YOUR_GROUP /media/YourVolume/automation
sudo chmod 775 /media/YourVolume/automation対象は、スクリプトが実際に必要とするディレクトリに限定してください。ディスク全体のルートに対して再帰的な変更を行わないでください。chmodマニュアルとchownマニュアルが、上流の公式リファレンスです。
ポリシーとリグレッションを見分ける方法
Files、SMB、アプリからのアクセスは機能している一方で、ボリュームルートへのシェルからの直接書き込みだけが失敗する場合、それは管理された権限モデルと整合する可能性があります。サポートされているデータ移行機能や共有UIがブロックされる場合は、正確なエラーとバージョンを記録してください。これは別種の障害であり、現行の安定版に対して検証する必要があります。
