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

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

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

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

ファイルが Access Control リスト (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 のネーム スペースに予約名が含まれています

ファイル名に、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 構文を使用して、名前に末尾のスペースまたは末尾のピリオドを含むファイルを開くと、実際のファイルが開かれる前に末尾のスペースまたはピリオドが削除されます。 たとえば、 と AFile.txt という名前AFile.txtの同じフォルダーに 2 つのファイルがあり、ファイル名の後のスペースを書き留めます。 標準の Win32 呼び出しを使用して 2 番目のファイルを開こうとすると、代わりに最初のファイルを開きます。 同様に、名前がスペース文字だけのファイルがあり、標準の Win32 呼び出しを使用してファイルを開こうとすると、代わりにファイルの親フォルダーが開きます。 このような状況では、これらのファイルのセキュリティ設定を変更しようとすると、できない場合や、異なるファイルの設定が予期せず変更される可能性があります。 この動作が発生した場合、実際には制限の厳しい ACL を持つファイルに対するアクセス許可があると思われる場合があります。

原因の組み合わせ

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

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

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

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