ファイルをNASに移動した後、なぜファイルの権限が壊れるのですか？

ファイルはコンピューター、外付けドライブ、ダウンロードフォルダーでは正常に動作していても、NASに移動すると読み取り専用になったり、アプリから見えなくなったり、アクセスできなくなることがあります。これは通常ファイルデータが破損していることを意味しません。ファイルが異なる所有権と権限モデルを持つ新しいファイルシステムに入ったことを意味します。

デバイス間の移動は一般的にコピーの後に元のファイルを削除する操作として行われます。NASは接続されたSMBまたはNFSのID、宛先フォルダーのACL、UIDとGIDの値、umask、コンテナユーザー、サーバー側の作成ルールを使って新しいファイルを作成します。問題を解決する最速の方法は、誰がファイルを作成し、現在誰が所有しているか、どのユーザーまたはプロセスが拒否されているかを特定することです。

ファイルをNASに移動すると通常新しいファイルが作成される

フォルダーをNASにドラッグすると、WindowsエクスプローラーやFinderでは普通の移動のように見えます。しかし実際には、元のディスクとNASは別のファイルシステムです。クライアントは元のデータを読み取り、新しい宛先オブジェクトを作成し、転送が成功した後に元のファイルを削除します。

これは同じファイルシステム内の2つのフォルダー間でファイルを移動する場合とは異なり、その場合システムはファイルのディレクトリ位置のみを更新することがあります。Microsoftのコピーと移動の動作の説明によると、別のボリュームにコピーされたオブジェクトは新しいフォルダーの権限を継承し、同じボリューム内の移動は通常既存の権限を保持します。

この違いは、「切り取りと貼り付け」がNASへの転送後に所有権、ACLエントリ、または拡張属性が同一のままであることを保証しない理由を説明します。宛先システムは単に元のファイルシステムオブジェクトを移動しているわけではありません。

宛先のACLが新しいファイルの継承を決定する

新しくコピーされたすべてのファイルが同じ予期しない権限を受け取る場合、親ディレクトリの方が元のファイルよりも重要であることが多いです。宛先には継承されたACLエントリ、デフォルトのPOSIX ACL、NFSv4 ACLフラグ、またはNAS固有の権限プリセットが存在する可能性があります。

たとえば、共有フォルダーは新しいファイルが家族グループ、メディアグループ、または特定のSMBアカウントのアクセス権を継承するように設定されることがあります。継承フラグが欠落していると逆の結果になることがあり、ユーザーはデータセットのルートにはアクセスできても、その中の新しいファイルにはアクセスできない場合があります。

TrueNASスタイルの権限システムはPOSIXとNFSv4/SMB ACLモデルを区別します。重要な挙動はNFSv4とSMB ACLの継承が新しいファイルやフォルダを制御できる一方、POSIXのデフォルトとデータセットの境界は異なる動作をすることです。個別のファイルを変更する前に、宛先フォルダのACLと継承フラグを確認してください。

NASは接続されたSMBアカウントを使用します

WindowsまたはmacOSのコンピューターがSMB経由でファイルをコピーすると、NASは通常クライアントコンピューターのローカルユーザーIDを保持しません。SMB共有に認証されたアカウント、またはそのセッションにマッピングされたアカウントとして宛先ファイルを作成します。

これが、ソースPCのWindowsユーザーが所有するファイルが kenneth, nasuser, guest、または転送後の別のNAS側のID。保存されたSMB資格情報により、あるコンピューターが別のコンピューターとは異なる所有者でファイルを作成することもあります。

デスクトップログインが使われていると仮定せず、アクティブなSMBユーザー名を確認してください。共有を切断し、必要に応じて古い資格情報をクリアし、ファイルの所有または管理を行うべきNASアカウントで再接続してください。

共有アクセスとファイルアクセスは別々の権限レイヤーです

ユーザーはSMB共有を開いてフォルダを閲覧できても、ファイルの編集、名前変更、削除ができない場合があります。これはネットワーク共有にアクセスできることを意味しますが、ファイルシステムが要求された操作を許可していることを証明するものではありません。

共有レベルのルールは、SMBまたはNFSクライアントが共有にアクセスできるかどうか、接続が読み取り専用か読み書き可能かを決定します。基盤となるファイルシステムは、各ファイルとディレクトリの所有者、グループ、モードビット、ACLエントリ、継承ルールを評価します。

両方のレイヤーをトラブルシュートしてください。読み書き可能とマークされた共有は、書き込みを拒否するファイルシステムのACLを上書きできず、許可されたファイルシステムモードは共有設定でSMBアカウントが制限されている場合には役に立ちません。

WindowsスタイルのACLとPOSIXモードは完全には対応しません

Windowsの権限は複数のユーザーとグループ、明示的な許可と拒否のエントリ、継承フラグ、読み取り、書き込み、削除、変更のための個別の権利を含むことができます。従来のPOSIXモードビットは所有者、グループ、その他へのアクセスに制限します。

SambaやNASのOSはこれらのモデル間で変換を行う必要があります。Windowsのセキュリティパネルは詳細なACLを表示することがありますが、 ls -l 単純化された表現のみを表示します。逆に、次のコマンドを実行すると chmod SMBクライアントが期待するWindowsスタイルのACLを正しく再構築せずにモードビットを変更する可能性があります。

NASのデータセットがNFSv4またはSMB ACLを使用している場合は、NASインターフェースまたはACL対応のコマンドで完全なACLを確認してください。ファイルが表示されているからといって rwxrwx--- 権限の全体像を説明します。

UIDとGIDの不一致はLinux、NFS、およびアプリに影響を与えます

Linuxシステムは通常、所有権を数値のユーザーIDとグループIDで決定します。ユーザー名はそれらの数字に関連付けられたラベルに過ぎません。

二つのシステムは両方とも media 一方がUID 1000を使い、もう一方がUID 1001を使う場合、LinuxやNFSにとってそれらは異なるIDです。UID 1000の所有ファイルは、UID 1001で実行されるアプリケーションからはアクセスできないことがあります。見た目のユーザー名が同じでもです。

NAS、ホスト、クライアント、アプリケーションの数値値を確認してください：

id media
ls -ln /path/to/files
stat /path/to/files/example.mkv

表示名だけでなく数値を比較してください。複数のシステムが同じストレージに書き込む必要がある場合は、必要なUID/GID値を揃えるか、正しい権限を持つ共有グループを作成してください。

SMBとNFSは異なるユーザーとして同じデータセットに書き込むことがある

SMBクライアントとNFSクライアントが同じディレクトリに書き込みアクセスを持つ場合、権限問題は徐々に現れることが多いです。SMB経由でアップロードされたファイルはあるNASユーザーに属し、NFS経由で作成されたファイルは別のシステムの数値UIDを持つことがあります。

両プロトコルは異なるACLやIDマッピングルールを適用することもあります。その結果、フォルダ内のファイルはユーザーから見ると同一に見えても、所有者、グループ、マスク、継承エントリが異なる場合があります。

可能な限り一つの主要な書き込みプロトコルを選択してください。SMBとNFSが同じデータセットを共有する必要がある場合は、数値ID、共有グループ、デフォルトACL、umask値、作成動作を揃えてから本番データを配置してください。

Dockerコンテナは別のユーザーIDを追加する

ファイルはSMB経由で読み取れる場合でも、Plex、Jellyfin、Nextcloud、ダウンローダー、バックアップコンテナからは利用できないことがあります。Dockerは正しいパスをマウントしても、コンテナ内のプロセスが読み書き権限を持たない場合があります。

コンテナのプロセスは独自のUIDとGIDで実行されます。そのIDがマウントされたNASパスの所有者や許可されたグループと一致しない場合、アプリケーションはアクセス拒否を受けます。 許可が拒否されましたボリュームマウントはディレクトリを見えるようにしますが、ファイルシステムの認証をバイパスするわけではありません。

一般的な解決策は、コンテナのUIDとGIDをマウントされたボリュームの使用を許可されたIDに合わせることです。Composeファイルに表示されるPUIDやPGIDフィールドだけに頼らず、実際のプロセスIDを確認してください：

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "書き込み可能"

あるコンテナはファイルを作成できるが、別のコンテナはそれを読み取れない

これはメディア自動化スタックでよく起こる問題です。ダウンロードコンテナが正常に完了したファイルを書き込みますが、メディアサーバーがそれをスキャンできなかったり、オーガナイザーが名前を変更できなかったりします。

アプリケーションは異なるUID/GID値や異なるumaskを使用している可能性があります。ダウンローダーがファイルを作成する場合 600、所有者だけが読み書きできます。例えば 640 グループ読み取りを許可しますが、両方のアプリケーションが正しいグループを共有している場合のみです。

共有アプリケーションディレクトリの場合、計画された所有者グループを使用し、必要なアプリケーションIDをそのグループに追加し、グループに必要なアクセス権を与えるumaskを選択してください。ダウンローダーが制限されたモードで新しいファイルを作成し続ける場合、古いファイルだけを修正しても効果はありません。

Umaskとサーバー作成ルールが新しい権限を制御します

古いファイルは動作するが新しいファイルがすべてアクセス不能な場合、作成プロセスが原因の可能性が高いです。各プログラムは要求されたファイルモードから始まり、umaskがファイル作成前に選択された権限を除去します。

Sambaはまた以下のような設定を使用することがあります 作成マスク, ディレクトリマスク, ユーザー強制、または グループ強制NASインターフェースはこれらを権限テンプレート、共有フォルダのプリセット、または継承オプションの背後に隠していることがあります。

Windows SMB、macOS SMB、NASファイルマネージャー、NFS、および関連する各コンテナを通じてテストファイルを一つずつ作成してください。結果の所有者、グループ、モード、ACLを比較します。これによりどの作成経路が権限の問題を引き起こしているかがすぐにわかります。

異なる転送ツールは異なるメタデータを保持します

Finder、Windowsエクスプローラー、NASのウェブインターフェース、 cp、および rsync 同一の結果を保証しません。タイムスタンプを保持するものもあれば、POSIXモードを保持できるもの、単に宛先のルールで新しいファイルを作成するものもあります。

移行方法を選ぶ前に、どのプロパティを保持すべきか決めてください：

• ファイル内容とディレクトリ構造
• 変更日時
• POSIX権限
• 所有者とグループ
• ACLエントリ
• 拡張属性
• シンボリックリンク

一般的な家族の文書やメディアファイルの場合、NASに存在しないソースコンピューターのアカウントを保持するよりも、宛先の継承が望ましいことがあります。アプリケーションデータ、Linuxのホームディレクトリ、またはサーバー移行の場合は、所有権やACLメタデータの保持が不可欠なことがあります。

Rsyncは基本的なコマンド一つで全ての属性を保持するわけではありません

Rsyncは制御されたNAS移行に便利ですが、結果はオプション、実行ユーザーの権限、およびソースと宛先のファイルシステムの機能に依存します。

アーカイブモードは、許可されている場合にモード、タイムスタンプ、グループ、所有権などの一般的なメタデータを保持します。rsyncで権限、ACL、および拡張属性を保持する必要がある場合は追加のオプションが必要です。典型的なLinux間のテストでは以下を使用することがあります：

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/ -A オプションはACLを保持し、 -X 両側がサポートしている場合に拡張属性を保持します。 --numeric-ids NASに有効なアカウントがない数値所有者を保持すると、避けようとしている不一致を再現する可能性があるため、意図的に使用する必要があります。

SMBマウントされたrsyncの宛先はNASファイルシステムのように動作しない場合があります

コンピューターからローカルにマウントされたSMB共有に対してrsyncを実行することは、SSH経由でNASのファイルシステムに直接rsyncを実行することと同じではありません。SMBレイヤーは所有者をマッピングしたり、ACLを変換したり、属性設定の試みを拒否したりすることがあります。

SMBコピーを実行するユーザーは、rsyncが要求しても任意の所有権を割り当てる権限を持っていない場合があります。宛先のファイルシステムは、元のものとは異なるACLモデルをサポートしている可能性もあります。

まず小さな代表的なディレクトリでテストしてください。転送後はクライアントのマウントされた共有だけでなく、NAS上のファイルを直接確認してください。所有権、モード、ACL、拡張属性、アプリケーションのアクセスを確認してから、完全なデータセットを移行してください。

NASの権限プリセットは単純なモードビットを上書きすることがあります

一部のNASシステムは、従来の所有者/グループ/その他のモードだけでなく、データセットのACLテンプレートや拡張メタデータを通じてアクセスを管理します。これにより手動での管理が複雑になることがあります。 chmod SMBやアプリケーションがアクセスを拒否し続ける一方で、成功したように見えることがあります。

データセットは、新しいファイルが作成されたときや管理インターフェースを通じて権限が編集されたときに継承ルールを再適用するように設定されている場合もあります。GUIで管理されるACLと繰り返しのコマンドライン変更を混在させると、一貫性のない状態になることがあります。

一つの権限モデルを選択し、一貫して管理してください。データセットがSMB/NFSv4 ACL用に設定されている場合は、POSIXモードコマンドで構造を繰り返し置き換えるのではなく、NASのACLエディターやACL対応ツールを使用してください。

NASの再インストールは必ずしもデータの権限をリセットしません

権限は通常、ファイルやファイルシステムのデータセットに属し、単にNASのオペレーティングシステムの設定に属するわけではありません。したがって、ブートシステムを再インストールしても、インポートされたストレージプール上の同じアクセス不能な所有権やACLエントリが残る可能性があります。

TrueNASコミュニティの事例は、ファイルシステムの権限がストレージプールに付随したままであることと、正しいユーザーおよびアクセス設定と一致させる必要があることを示しています。また、意図したアイデンティティモデルを理解せずに大規模な再帰的変更を行うリスクも示しています。

サービスを再インストールまたは再構築する前に、データセットの所有者、グループ、ACL、およびアプリケーションユーザーを調査してください。データは無傷で、アクセスルールを正しく復元するだけで済む場合があります。

再帰的なchmod 777が本当の解決策でない理由

数千のファイルがアクセス不能になる場合、 chmod -R 777 アクセスを迅速に復元する方法のように見えます。所有者、グループ、およびすべてのローカル識別情報に読み取り、書き込み、実行権限を付与します。

それはプライベートデータを露出させ、無関係なサービスがファイルを変更できるようにし、通常のドキュメントに実行権限を設定し、慎重に継承されたACL構造を破壊する可能性があります。また、誤った所有者、不一致のコンテナUID、欠落したグループメンバーシップ、壊れたSMB識別マッピングを修正しません。

代わりに意図されたアクセスモデルを使用します：正しい所有者と共有グループを設定し、適切なACLを再構築し、ディレクトリとファイルのモードを別々に設定し、将来の継承とumask設定を修正します。再帰的な変更を適用する前に小さなフォルダでテストしてください。

識別情報から外側へ権限を修復する

修正を期待するコマンドではなく、拒否されたユーザーまたはプロセスから始めます。人間のSMBユーザー、メディアサーバー、バックアップコンテナは異なるアクセスレベルを必要とする場合があります。

影響を受ける各ワークフローについて記録する：

• アクセスを試みているユーザーまたはプロセス
• 該当する場合の数値UIDとGID
• 使用されているプロトコルまたはマウント
• ファイルの現在の所有者とグループ
• 完全なACLと継承されたエントリ
• 実際に必要なアクセス：読み取り、作成、変更、または削除

次に、誤っている層だけを修正します。ユーザーを許可されたグループに追加し、所有権を修正し、ACLを修復し、コンテナUIDを整合させ、作成ルールを更新します。ワークフローに必要な以上の広範なアクセス権を与えないでください。

階層的なトラブルシューティングの順序に従う

共有ACL、コンテナ識別情報、NFSエクスポート、ファイルモードを同時に変更すると有用な証拠が失われます。権限の層ごとに1つずつテストしてください。

影響を受けたファイル1つとユーザーまたはアプリケーション1つから始めます。その小さなケースが機能したら、通常のワークフローで新しいファイルを作成し、修正が問題の再発を防ぐことを確認します。

大規模なNAS移行前に権限問題を防ぐ方法

数十万のファイルにわたる権限の修復は、移行前にアクセスモデルをテストするよりもはるかに困難です。最終データセットに計画されているのと同じACLおよびアプリケーション構成を持つ小さな宛先フォルダーを作成してください。

複数のファイルタイプ、ネストされたディレクトリ、読み取り専用ファイル、実行可能スクリプト、および拡張属性付きファイルをコピーします。SMB、NFS、NASインターフェース、バックアップソフトウェア、および関連コンテナの各パスからテストしてください。

新しいファイルが一貫して正しい所有者、グループ、ACL、およびアプリケーションアクセスを受け取るまで、完全な移行を開始しないでください。既存データに対して再帰的な所有権や権限の変更を適用する前に、スナップショットやバックアップを保持してください。

最終的な結論

データをNASに移動した後にファイル権限が壊れるのは、転送時に新しいファイルシステムオブジェクトが作成されるためです。これらのオブジェクトは、転送に使用されたNASアカウント、宛先のACL、UID/GID値、umask、プロトコルマッピング、およびアプリケーションやコンテナのIDによって管理されます。

これで始めないでください chmod 777まず3つの質問に答えます：誰がファイルを作成したか、現在の所有者は誰か、どのIDが拒否されているか。その後、共有アクセス、ファイルシステムのACL、継承、コンテナID、および将来の作成ルールを調査します。

修復が成功すると、既存ファイルへの適切なアクセスが復元され、NAS上で次にコピー、ダウンロード、または作成されるファイルが自動的に正しい権限を受け取ることが保証されます。

よくある質問

なぜコピーしたファイルはNASフォルダーの権限を継承するのですか？

NASへの転送は通常、別のファイルシステム上に新しいファイルを作成します。新しいオブジェクトは一般的に、宛先フォルダーのACL、継承フラグ、およびサーバー側の作成ルールから権限が割り当てられます。

なぜSMB経由でNASファイルを開けるのに、Dockerコンテナでは開けないのですか？

SMBセッションとコンテナは異なるIDを使用しています。コンテナの実際のUIDとGID、マウントされたパスの数値所有権、グループメンバーシップ、およびマウントが読み取り専用かどうかを確認してください。

NAS共有の修復にchmod 777を使うべきですか？

いいえ。すべてのローカルIDに広範なアクセス権を付与し、ACLの継承を損なう可能性があり、所有権やUID/GIDの誤ったマッピングを解決しません。意図したユーザーとグループを定義し、それに応じて所有権とACLを修復してください。

rsyncはNASのファイル権限を保持できますか？

選択したオプション、実行権限、および両方のファイルシステムが対応している場合、POSIX権限やその他のメタデータを保持できます。ACLや拡張属性には、追加のオプションが必要です。 -A および -X.

古いファイルを修復したのに、新しいファイルが次々と壊れるのはなぜですか？

作成パスがまだ間違っています。宛先フォルダーの継承されたACL、SMBまたはNFSのID、アプリケーションのumask、Sambaの作成ルール、およびコンテナのUID/GIDを確認してください。