マウントされたファイルシステムでは、ファイルを作成できるのに名前の変更が拒否されるのはなぜですか？
マウントされたファイルシステムではファイルを作成できても、名前の変更が拒否されることがあります。これは、名前の変更にディレクトリ、所有権、境界、フラグ、オープンハンドルに関する個別の要件があるためです。
マウントが成功したことは、ファイルシステムが接続されたことを示すだけです。また、ファイルの書き込みが成功しても、クライアントが少なくとも1つのオブジェクトを作成または変更できることしか証明できません。名前の変更はディレクトリエントリの操作であり、移動元と移動先の両方のディレクトリへの権限、削除権限、同一ファイルシステム上のパス、有効なターゲット名、競合するSMB共有モードや保護ファイルフラグがないことなどが必要になる場合があります。ファイルシステムが破損していると判断する前に、正確なエラーを記録し、作成、名前変更、移動、削除を個別に比較してください。
権限を変更する前に、正確な名前変更エラーを記録する
ホストと影響を受けているクライアントから、それぞれ1回ずつ名前変更を再実行します。元のパス、移動先のパス、ユーザーID、ファイルシステム、マウントポイント、エラーコード、移動先の名前がすでに存在するかどうかを記録してください。
Linuxのrenameシステムコールのエラーでは、権限の失敗、ビジー状態のマウントポイント、デバイスをまたぐ移動、読み取り専用ファイルシステム、空でないターゲット、その他の状態が区別されます。これらはグラフィカルなファイルブラウザーでは同じように見えることがあります。
新しいファイルの作成には成功するのに名前の変更に失敗する場合は、その違いを維持して確認してください。通常の書き込みアクセスではなく、ディレクトリエントリの置換、削除権限、命名規則、ロック、パスの境界に問題がある可能性が高くなります。
両方の親ディレクトリの権限を確認する
元の名前を含むディレクトリと、新しい名前を含めるディレクトリについて、所有権、モードビット、ACL、有効なユーザーIDを確認します。名前変更の権限は、ファイルの書き込みビットではなく、主にディレクトリによって決まります。
Red Hatは、共有書き込み可能なディレクトリではスティッキービットが名前変更と削除を制限すると説明しています。複数のユーザーがファイルを作成できる場合でも、ファイル所有者、ディレクトリ所有者、または特権ユーザーにしか操作できないことがあります。
エラーが発生するのと同じNASユーザーでテストしてください。管理者で成功しても、通常のアカウントが両方のディレクトリエントリに対する削除権限や名前変更権限を持っているとは限りません。
不変、削除不可、追加専用のフラグを確認する
通常の権限やACLに加えて、ファイルと親ディレクトリのファイルシステムフラグを確認します。復元処理、セキュリティツール、保持ポリシーのワークフローによって、基本的な権限一覧には表示されないフラグが維持されていることがあります。
FreeBSDのセキュリティハンドブックでは、不変ファイルフラグによって変更や削除が防止されると説明されています。追加専用フラグや削除不可フラグも、名前変更に必要なディレクトリ変更を妨げることがあります。
保護フラグを設定したポリシーやアプリケーションを特定してから、フラグを解除してください。フラグを一括で解除すると、保持、バックアップ、ランサムウェア対策の制御が無効になるおそれがあります。
1つのフォルダーツリーに隠れたファイルシステム間の移動を除外する
元のディレクトリと移動先のディレクトリについて、デバイスID、マウントポイント、バインドマウント、データセット、コンテナパスを確認します。同じ共有フォルダー内にある2つのフォルダーでも、異なるマウント済みファイルシステムに属している場合があります。
GNU Cライブラリでは、EXDEVをデバイス間の名前変更エラーと定義しています。上位レベルの移動ツールはコピーと削除で処理を続行できる場合がありますが、アトミックな名前変更を想定するアプリケーションでは単純に失敗することがあります。
ローカルでの移動がファイル全体のコピーによってのみ成功する場合、それはアトミックな名前変更ではありません。アプリケーションの一時パスと最終パスを修正するか、両方の処理を同じファイルシステム上で行ってください。
オープンハンドルとSMBの削除共有を確認する
元のディレクトリと移動先のディレクトリについて、オープンファイルとSMBセッションを一覧表示します。プレビューアー、サムネイル生成ツール、エディター、メディアスキャナー、ウイルス対策ツール、バックアップクライアントを1つずつ終了させてください。
Microsoftは、開いたサムネイルキャッシュのハンドルによって名前変更がブロックされるネットワークフォルダーの事例を説明しています。これは、他のファイルを読み取ったり作成したりできても、特定のオブジェクトに対する共有違反が解消されるわけではないことを示しています。
オープンハンドルの証拠を保存する前に、NAS全体を再起動しないでください。再起動によってロックは解除されるかもしれませんが、どのクライアントやサービスがロックを作成し直したのか分からなくなる可能性があります。
SMBの名前変更規則とクライアントのファイル名を比較する
同じディレクトリで、単純な小文字のASCII名を試します。その後、大文字と小文字だけを変更した名前、予約文字、末尾のピリオドやスペース、Unicode正規化、既存の移動先名を比較してください。
SambaのmacOS相互運用モジュールには、POSIX名前変更互換オプションがあります。これは、クライアントとサーバーの命名規則によって、ディレクトリの名前変更が受け入れられるかどうかが変わることを示しています。
特定のファイル名パターンだけが失敗する場合は、正規化する前に元の名前の対応関係を保存してください。ロールバック用の一覧なしに一括で名前を変更すると、メディアライブラリ、同期ジョブ、ショートカット、バックアップが壊れる可能性があります。
原因が確認できた層だけを修正し、すべての操作を検証する
親ディレクトリの権限、スティッキービットの所有権、保護フラグ、同一ファイルシステム上のパス、オープンハンドル、互換性のないファイル名など、確認できた原因だけを修正します。元のユーザーとアプリケーションでテストを繰り返してください。
ZimaSpaceの大文字と小文字だけが異なるファイル名の衝突に関する記事では、移動先で2つの名前が同一とみなされる、より限定的なクロスプラットフォームのケースを扱っています。
再接続と再起動の後、意図したパスで、作成、クローズ、名前変更、移動、削除、再作成のすべてが成功すれば、問題は解決しています。ファイルシステムが読み取り専用になった場合や、破損またはハードウェアI/Oエラーが報告された場合は、書き込みを停止してください。
よくある質問
ファイルは作成できるのに、なぜ名前を変更できないのですか？
ファイルの作成にはディレクトリエントリを追加する権限が必要ですが、名前の変更では、古いエントリを削除する権限、両方の親ディレクトリへの書き込み・実行権限、互換性のある命名規則、保護フラグや競合するハンドルがないことも必要になる場合があります。
EXDEVの名前変更エラーは、ファイルシステムが破損しているという意味ですか？
いいえ。通常は元の場所と移動先が異なるファイルシステム上にあるため、カーネルが1回のアトミックな名前変更を完了できないことを意味します。コピーと削除による移動なら成功する場合があります。
開いているファイルの名前を変更できますか？
多くのローカルPOSIXファイルシステムでは可能ですが、SMBクライアントやアプリケーションが削除共有なしでファイルを開くことがあります。その場合、ハンドルが閉じるまでサーバーは名前変更を拒否します。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
