NTFS ファイル システム ボリューム上のファイルまたはフォルダーを削除することはできません

この記事では、NTFS ファイル システム ボリューム上のファイルまたはフォルダーを削除できない理由について説明します。 また、この問題の解決にも役立ちます。

適用対象:  Windows Server 2012R2
元の KB 番号:   320081

注意

内部的には、NTFS はフォルダーを特別な種類のファイルとして扱います。 したがって、この記事 の単語 file は、ファイルまたはフォルダーのいずれかを示します。

原因 1: ファイルが ACL を使用する

ファイルがアクセス制御リスト (ACL) を使用している場合は、ファイルを削除できません。 この問題を解決するには、ファイルのアクセス許可を変更します。 アクセス許可を変更するには、ファイルの所有権を取得する必要があります。

管理者は、ファイルに対するアクセス許可が明示的に付与されていない場合でも、ファイルの所有権を暗黙的に取得できます。 ファイル所有者は、ファイルへのアクセス許可が明示的に付与されていない場合でも、ファイルのアクセス許可を変更する暗黙的な機能を持っています。 したがって、ファイルの所有権を取得し、ファイルを削除するためのアクセス許可を自分自身に与え、ファイルを削除する必要があります。

ファイルに標準以外の ACL が含まれていますので、特定のセキュリティ ツールを使用してアクセス許可を表示または変更することはできません。

この問題を回避するには、別のツールを使用します (たとえば、新しいツールのビルドなどCacls.exe。

ACL のアクセス制御エントリ (AES) には、その種類に応じて特定の優先シーケンスがあります。 たとえば、アクセスを拒否する ACEs は、通常、アクセスを許可する ACEs の前に来ます。 ただし、プログラムが任意のシーケンスで ACEs を持つ ACL を書き込むのを妨げるものは何もありません。 以前のバージョンのバージョンでは、Windows ACL を読み取ろうとWindows問題が発生しました。 Microsoft エクスプローラーのグラフィカル セキュリティ エディターを使用して、これらの ACL をWindowsできない場合があります。 この問題は、以降のバージョンのバージョンで修正Windows。 この問題が発生した場合は、最新バージョンの Cacls.exe。 ACL を表示または編集できない場合でも、新しい ACL を記述してファイルにアクセスできます。

原因 2: ファイルが使用されている

ファイルが使用されている場合は、ファイルを削除できません。 この問題を解決するには、開いているハンドルを持つプロセスを特定し、そのプロセスを閉じます。

ファイルの開き方によっては、使用しているファイルを削除できない場合があります。 たとえば、ファイルは共有アクセスではなく排他的アクセス用に開きます。 さまざまなツールを使用して、ファイルに対して開いているハンドルを持つプロセスをいつでも決定できます。

この問題の症状は異なる場合があります。 [削除] コマンドを使用してファイルを削除できます。 ただし、ファイルを開いているプロセスがファイルを解放するまで、ファイルは削除されません。 さらに、削除が保留中のファイルの [セキュリティ] ダイアログ ボックスにアクセスできない場合があります。 この問題を解決するには、開いているハンドルを持つプロセスを特定し、そのプロセスを閉じます。

原因 3: ファイル システムの破損によってファイルへのアクセスが妨げている

ファイル システムが破損している場合は、ファイルを削除できます。 この問題を解決するには、ディスク ボリュームで Chkdsk ユーティリティを実行して、エラーを修正します。

次の理由により、ファイル システムが破損し、ファイルが問題のある状態になる可能性があります。

  • ディスク上の不良セクタ
  • その他の障害のあるハードウェア
  • ソフトウェアのバグ

一般的な操作は、さまざまな方法で失敗することがあります。 ファイル システムが破損を検出すると、イベントがイベント ログに記録され、通常、Chkdsk の実行を求めるメッセージが表示されます。 破損の性質によっては、Chkdsk はファイル データを回復する場合と復元しない場合があります。 ただし、Chkdsk はファイル システムを内部的に一貫性のある状態に戻します。

原因 4: ファイルがパス内に存在し、パスのMAX_PATHします。

ファイル パスに問題がある場合は、ファイルを開く、編集する、または削除できない。

解決策 1: 自動生成された 8.3 の名前を使用してファイルにアクセスする

この問題を解決するには、自動生成された 8.3 名を使用してファイルにアクセスできます。 フォルダー名が長すぎるため、パスが深い場合は、この解決が最も簡単な解決方法です。 8.3 パスも長すぎる場合、またはボリュームで 8.3 の名前が無効になっている場合は、解決策 [2] に移動します。 NTFS ボリュームで 8.3 ファイル名を無効にする方法の詳細については、「NTFS パーティションで 8.3名の作成を無効にする方法」を参照してください。

解決策 2: 深いフォルダーの名前を変更または移動する

フォルダーの名前を変更して、ターゲット ファイルが存在しなくなったファイルよりも深 MAX_PATH い名前を付ける。 そうする場合は、ルート フォルダーまたは他の便利な場所から開始します。 次に、フォルダーの名前を短く変更します。 この手順でこの問題が解決しない場合 (たとえば、ファイルの深さが 128 フォルダーを超える場合)、解決策 4 に進みます

解決策 3: パスの構造内のフォルダーにドライブをマップする

ターゲット ファイルまたはフォルダーのパスの構造内のフォルダーにドライブをマップします。 このメソッドは、仮想パスを短くします。

たとえば、次のように構造化されたパスを使用するとします。

\\ServerName\SubfolderName1\SubfolderName2\SubfolderName3\SubfolderName4\...

このパスでは、合計文字数が 255 文字を超える。 このパスの長さを 73 文字に短くするには、ドライブをサブフォルダー名4 にマップします。

解決策 4: フォルダーと同じ深さにあるネットワーク共有を使用する

解決策 1、2、3 が便利でない場合、または問題を解決しない場合は、できる限りフォルダー ツリーの深いネットワーク共有を作成します。 次に、共有にアクセスしてフォルダーの名前を変更します。

解決策 5: 深いパスを走査できるツールを使用する

多くのWindowsプログラムでは、パスの最大長が 255 文字より短くなると予想されます。 これらのプログラムは、これらの一般的なパスを処理するのに十分な内部記憶域のみを割り当てる。 NTFS にはこの制限はありません。また、はるかに長いパスを保持できます。

既にかなり深いフォルダー構造のある時点で共有を作成し、共有を使用してその時点より下に深い構造を作成すると、この問題が発生する可能性があります。 フォルダー ツリーでローカルに動作するツールの中には、ルートからツリー全体を走査できない場合があります。 これらのツールを特別な方法で使用して、共有を走査する必要がある場合があります。 CreateFile API のドキュメントでは、このような状況でツリー全体を走査するメソッドについて説明します。

通常、ファイルを作成するソフトウェアを使用してファイルを管理できます。 より深いファイルを作成できるプログラムがある場合は、通常、同じプログラムを使用してファイルを MAX_PATH 削除または管理できます。 通常、同じ共有を使用して、共有上に作成されたファイルを削除できます。

原因 5: ファイル名には、Win32 ネーム スペースに予約名が含まれています

ファイル名に、lpt1 などの Win32 ネーム スペースに予約名が含まれる場合は、ファイルを削除できます。 この問題を解決するには、Win32 以外のプログラムを使用してファイルの名前を変更します。 POSIX ツール、または適切な内部構文を使用してファイルを使用する他のツールを使用できます。

さらに、いくつかの組み込みコマンドを使用して、特定の構文を使用してファイルのパスを指定する場合、一般的な Win32 予約名チェックをバイパスできます。

一般的な Win32 CreateFile メカニズムを使用してファイルのハンドルを開いた場合、特定のファイル名は古いスタイルの DOS デバイス用に予約されます。 下位互換性のために、これらのファイル名は許可されません。また、通常の Win32 ファイル呼び出しを使用して作成することはできません。 この問題は NTFS の制限ではありません。

Win32 プログラムを使用すると、より深いフォルダーをスキャンするために使用するのと同じ手法を使用して、ファイルの作成または削除時に行われる一般的な名前チェックをバイパスできます MAX_PATH 。 さらに、一部の POSIX ツールでは、これらの名前チェックの対象とならない場合があります。

原因 6: ファイル名に Win32 ネーム スペースに無効な名前が含まれている

ファイル名に無効な名前が含まれている場合は、ファイルを削除できます。 たとえば、ファイル名には末尾のスペースまたは末尾のピリオドが含むか、ファイル名はスペースだけで作ります。 この問題を解決するには、適切な内部構文を使用してファイルを削除するツールを使用します。 これらのファイルを操作 "\\?\" するには、いくつかのツールで構文を使用できます。 次に例を示します。

del "\\?\c:\<path_to_file_that contains a trailing space.txt>"

この問題の原因は、原因 4 に似ています。 通常の Win32 構文を使用して、末尾のスペースまたは末尾のピリオドが名前に含まれているファイルを開く場合、実際のファイルを開く前に末尾のスペースまたはピリオドが削除されます。 たとえば、同じフォルダーに 2 つのファイル名を付け、ファイル名の後 AFile.txt AFile.txt にスペースをメモします。 標準の Win32 呼び出しを使用して 2 番目のファイルを開く場合は、代わりに最初のファイルを開きます。 同様に、名前がスペース文字のファイルを持ち、標準の Win32 呼び出しを使用して開く場合は、代わりにファイルの親フォルダーを開きます。 このような場合は、これらのファイルのセキュリティ設定を変更しようとする場合、そうできないか、または異なるファイルの設定を予期せず変更する可能性があります。 この動作が発生した場合は、実際に制限的な ACL を持つファイルに対するアクセス許可を持っている可能性があります。

原因の組み合わせ

場合によっては、これらの原因の組み合わせが発生する場合があります。 ファイルを削除する手順をより複雑にできます。 たとえば、コンピューターの管理者としてログオンすると、原因 1 (ファイルを削除するアクセス許可が付与されません) と原因 5 (ファイル名には、ファイル アクセスを別のファイルまたは存在しないファイルにリダイレクトする末尾の文字が含まれている) の組み合わせが発生し、ファイルを削除できません。 ファイルの所有権を取得してアクセス許可を追加して原因 1 を解決しようとする場合は、ユーザー インターフェイスの ACL エディターが原因で原因 6が原因で適切なファイルにアクセスできないので、ファイルを削除できない場合があります。

この状況では、スイッチ (このユーティリティはリソース キットに含まれています) で Subinacl ユーティリティを使用して、アクセスできないファイルの所有権とアクセス許可を変更 /onlyfile できます。 次に例を示します。

subinacl /onlyfile "\\?\c:\<path_to_problem_file>" /setowner= domain\administrator /grant= domain\administrator=F

注意

このコマンドは、読みやすさのためにラップされた 1 つのコマンド ラインです。

このサンプル コマンド ラインは、末尾にスペースを含むファイルを変更し、domain\administrator アカウントがファイルの所有者であり、このアカウントがファイルを完全に C:\<path_to_problem_file> 制御します。 これで、同じ構文で Del コマンドを使用してこのファイルを削除 "\\?\" できます。