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

  • [アーティクル]

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

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

注:

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

原因 1: ファイルで ACL が使用されている

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

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

ファイルに非正規 ACL があるため、特定のセキュリティ ツールを使用してアクセス許可を表示または変更することはできません。

この問題を回避するには、別のツール (後のビルドのCacls.exeなど) を使用します。

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

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

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

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

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

原因 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 文字に短くするには、ドライブを SubfolderName4 にマップします。

解決策 4: フォルダーの深いネットワーク共有を使用する

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

解決策 5: ディープ パスを走査できるツールを使用する

多くの Windows プログラムでは、パスの最大長が 255 文字未満であることが予想されます。 これらのプログラムは、これらの一般的なパスを処理するのに十分な内部ストレージのみを割り当てます。 NTFS にはこの制限がないため、長いパスを保持できます。

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

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

原因 5: ファイル名に Win32 名前空間に予約名が含まれている

ファイル名に予約名が Win32 名前空間 (lpt1 など) に含まれている場合は、ファイルを削除できません。 この問題を解決するには、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.txtAFile.txt の後の領域をメモします。 標準の Win32 呼び出しを使用して 2 番目のファイルを開こうとした場合は、代わりに最初のファイルを開きます。 同様に、名前がスペース文字だけのファイルがあり、標準の Win32 呼び出しを使用して開こうとする場合は、代わりにファイルの親フォルダーを開きます。 このような場合は、これらのファイルのセキュリティ設定を変更しようとすると、その設定ができない場合や、異なるファイルの設定が予期せず変更される可能性があります。 この動作が発生した場合は、実際に制限付き ACL を持つファイルに対するアクセス許可があると思われる場合があります。

原因の組み合わせ

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

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

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

注:

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

このサンプル コマンド ラインは、ドメイン\管理者アカウントがファイルの C:\<path_to_problem_file> 所有者であり、このアカウントがファイルを完全に制御できるように、末尾の領域を含むファイルを変更します。 同じ "\\?\" 構文で Del コマンドを使用して、このファイルを削除できるようになりました。