新しいZimaOSメンバーに共有インターフェースで「読み取りと書き込み」権限を付与しても「権限がありません」と表示される場合は、ストレージプール全体に対して直ちに再帰的な所有権変更コマンドを実行しないでください。2026年3月の元スレッドでは、複数の所有権に関する仮説を検証し、完全なリセットも実施しましたが、確定した根本原因には至りませんでした。
確実なトラブルシューティング方法は、ZimaOS／Sambaの権限レイヤーと、基盤となるLinuxの所有権レイヤーを切り分けることです。まず小さな新規フォルダーで問題を再現し、管理者とメンバーのアクセスを比較してから、対象となる正確なホストパスを調べます。
UI上ではメンバー権限は正しく見えた
管理者アカウントはデータにアクセスできましたが、Andresという名前で新しく作成したアカウントには読み取り／書き込み権限が割り当てられていたにもかかわらず、ファイルを開くと権限エラーが発生しました。
現在のZimaOSはユーザーごとのSamba権限に対応
現在のZimaOSのドキュメントでは、メンバーアクセスとゲストアクセスが区別されており、管理者はSamba共有に「読み取り」または「読み取りと書き込み」のいずれかの権限を付与できます。「読み取りと書き込み」権限を持つメンバーは、基盤となるファイルシステムにアクセスできることを前提に、共有内のファイルをダウンロード、アップロード、名前変更、削除できるはずです。
現在のZimaOSマルチユーザーSamba設定を基準にしてから、古いスレッドからコピーしたシェルレベルの修正を使用するのが適切です。
新しく作成したテストフォルダーで問題を再現する
対象のデータディスク上に、現在のFilesインターフェースから小さなテストフォルダーを作成します。そのフォルダーだけを新しいメンバーに「読み取りと書き込み」権限で共有し、メンバーの認証情報を使ってメンバーのクライアントから接続します。
テストフォルダーは機能するものの、移行済みまたは古いディレクトリで失敗する場合、問題はそれらのパスまたは所有権に関連している可能性があります。新しいUIで作成したばかりのフォルダーでも失敗する場合は、問題がより広範囲に及んでいるため、従来のファイル所有権ではなく、アカウント、Samba、またはZimaOSの権限に関する問題の可能性として扱うべきです。
Linux の所有権は、無条件に修正するのではなく診断の手掛かりとして使用する
スレッドではユーザー ID とディレクトリの所有権を調べ、以下のパスにあることが分かりました。 /DATA/.media 異なる Linux ユーザーとグループが所有していました。そのため、移行済みデータで所有権の不一致が起きている可能性が考えられました。
再帰的な chown この操作により、アプリケーションが管理するデータ内で多数の「操作は許可されていません」というエラーが発生しました。これは、広範なシステムツリーや AppData ツリー全体に1つの所有権コマンドを適用することへの警告です。所有権を再帰的に変更すると、特定の UID や GID を必要とするコンテナやサービスが壊れる可能性があります。
次を使用してください。 id, ls -ld、正確にどのパスで失敗しているかを把握するための小さなテストファイル。無関係なアプリケーションディレクトリは変更しないでください。
工場出荷時リセットは確認済みの解決策ではない
再フォーマットして再インストールした後も、投稿者はメンバー権限のエラーを報告しました。この結果は重要です。ユーザーアクセスの問題に対する通常の解決策として、破壊的なリセットを推奨しないでください。
問題を報告する前に収集する情報
現在の ZimaOS で新しく作成したフォルダーでも、新規作成したメンバーに対してアクセスできない場合は、ZimaOS のバージョン、共有パス、メンバーの権限設定、クライアントのオペレーティングシステム、正確なエラー内容、管理者アクセスが機能するかどうかを記録してください。また、 id 該当するアカウントで ls -ld 影響を受けたパスだけに対して。
その証拠は、さらに大規模な所有権変更を行うよりも有用です。元のスレッドでは、クリーンインストールでの再現が予想外の事象であり、より深い調査に値するとコミュニティが判断して終わっており、1行で解決できることが確認されたわけではありません。
