ファイルサーバーの移行後、突然マッピングドライブからコピー＆ペーストができなくなると、日々の業務に大きな支障が生じます。本記事では、その原因や解決策を分かりやすく解説し、スムーズな運用を取り戻すためのポイントをお伝えします。
共有ドライブへのファイルコピーができない問題とは
ファイルサーバー移行後、一部のマッピングドライブでファイルをコピー＆ペーストできないという事象は、Windows環境ではまれに起こる問題です。具体的には以下のような状況が報告されることが多くあります。
- 以前のファイルサーバーから新しいファイルサーバーにデータを移行した後、特定のマッピングドライブ（例：O:ドライブ）においてのみファイルの貼り付けが失敗する
- 同じ共有フォルダをUNCパス（例：\FileServer1\Shared）で直接参照した場合には、問題なくファイルのコピー＆ペーストが行える
- 共有権限(Share permissions)は「Everyone: フルコントロール」になっていても、なぜかマッピングドライブ経由でのコピーが拒否される
こうした現象は、NTFS権限との不整合やクライアント側のマッピング情報の不具合など、複数の要因が絡んで起きる場合があります。
問題の原因を考える
問題の原因を正しく捉えることで、最適な解決策を導き出すことができます。代表的な原因をいくつか挙げてみましょう。
原因1：共有設定の破損・不整合
ファイルサーバーで共有フォルダを設定する際、Share permissions（共有権限）とNTFS権限の両方を正しく構成する必要があります。
移行時に共有名を変更したり、あるいは「別のディスク上のフォルダ」に旧サーバーの設定をコピーした場合などで、共有に関するメタ情報が不整合を起こすケースがあります。特にレジストリ情報や共有に付随する「アクセス制御リスト(ACL)」に破損が生じ、マッピングドライブだけ動作不良を起こす可能性があります。
原因2：クライアント側のマッピングドライブ情報のキャッシュ
クライアント側のマッピングドライブ情報が古い状態でキャッシュされており、実際のサーバー上の権限設定と整合性が取れなくなる場合があります。Windowsクライアントはマッピングドライブに関する情報をレジストリや資格情報マネージャー(Windows Credential Manager)などに保持しており、それが「更新前の情報」のまま残っているとアクセス不可になることがあります。
原因3：NTFS権限と共有権限の食い違い
Share permissionsでは「Everyone: フルコントロール」となっていたとしても、NTFS権限（フォルダのプロパティ -> セキュリティタブ）で実質的に書き込みが拒否されている場合があります。移行作業で所有者情報やアクセス権限が正しく引き継がれず、結果として一部ユーザーやグループに「書き込み不可」の設定が掛かっていることも少なくありません。
原因4：グループポリシーによる制限
企業や組織では、グループポリシー(GPO)を使ってフォルダリダイレクトやドライブマッピングの設定を一括管理することがあります。このGPOの設定が意図せず上書きされ、特定の共有ドライブだけアクセス制限が強化されているケースも想定されます。また、ソフトウェアの制限ポリシーが原因でマッピングドライブ経由の書き込みだけ遮断されてしまうことも考えられます。
原因5：サーバー側ソフトウェア・ファイアウォール・ウイルス対策の影響
サーバー上で動作しているウイルス対策ソフトやファイアウォールの設定が、特定のドライブマッピングからの書き込みをブロックしている例もあります。たとえば、リアルタイムスキャンが一時的に高負荷状態になっており、コピー動作を誤検知してブロックしているか、またはネットワーク経由での書き込みトラフィックを制限している場合などです。
解決策・対処方法
ここからは、具体的な解決策をステップバイステップで解説します。単に権限を見直すだけでなく、問題の切り分けやログの確認など、複合的なアプローチが重要です。
1. 共有の再作成（再設定）
なぜ再設定が有効か
- 共有設定の情報が破損している場合、いくら権限を修正しても直らないケースがあります。
- Windows Serverは共有名や共有プロパティをレジストリに保持するため、古い情報が残っていると不具合が継続する可能性があります。
具体的な手順例
- サーバー管理ツールやエクスプローラーから、共有フォルダのプロパティを開く
- 共有タブを選択し、一度「共有の削除」を行う
- データ（物理フォルダ自体）は削除されないのでご安心ください
- 再度「新しい共有」を作成し、適切な共有名・権限を再設定する
- クライアントPCからドライブマッピングし直し、動作をテストする
2. NTFS権限と共有権限の再確認
「Everyoneにフルコントロール」の落とし穴
- 共有権限で「Everyone:フルコントロール」を設定していても、NTFSレベルのセキュリティが「読み取り専用」になっていると書き込みできません。
- 管理者がファイルサーバー上のフォルダをコピーした際に、継承設定が変更され、サブフォルダには全く別の権限が適用されていることもあります。
権限確認のポイント
- エクスプローラーで該当の共有フォルダを右クリック -> プロパティ -> セキュリティタブ
- [グループ名またはユーザー名]欄で「Authenticated Users」または「Domain Users」などに「変更(Modify)」や「書き込み(Write)」が付与されているか確認
- 所有者(Owner)が正しく移行されているか、あるいは「所有権の取得」を行う必要がないかを確認
以下のように表を作って権限の整理を行うと、どのユーザー・グループがどのアクセス権を持っているかが明確になります。
| ユーザー/グループ | 共有権限 (Share) | NTFS権限 | 結果 |
|---|---|---|---|
| Everyone | フルコントロール | 読み取り | 読み取りのみ |
| Domain Users | フルコントロール | フルコントロール | 書き込み可 |
| Administrators | フルコントロール | フルコントロール | 書き込み可 |
| 特定の部署グループ | 変更 (Change) | 変更(Modify) | 書き込み可 |
このように、どこかで「読み取り専用」または「拒否」が設定されていないかを細かくチェックしましょう。
3. マッピングドライブの再設定
クライアント側のキャッシュクリア
- Windowsクライアントは、一度マッピングしたドライブに関する情報をレジストリや資格情報マネージャーに保持します。
- 何らかの理由で古い接続情報が残っている場合、実際にサーバー上の権限が変更されていても反映されないことがあります。
再マッピング手順
- エクスプローラー上でマッピング済みのドライブを右クリックし、「切断」を選択
- 再度「ネットワークドライブの割り当て」を行い、同じまたは別のドライブ文字を割り当て
- 「完了前に資格情報を入力する」もしくは「サーバーに自動接続する」オプションを選択し、正しい資格情報を入力
- その後、ファイルコピー＆ペーストが行えるかテスト
4. サーバー側のイベントログやエラーログの確認
イベントビューアでの確認
- Windows Serverの「イベントビューア」を開き、特に「Windowsログ -> セキュリティ」や「システム」にエラーメッセージや警告が記録されていないかをチェックします。
- アクセス拒否(Access Denied)系のイベントがあれば、そのイベントIDや詳細情報から原因を特定できます。
ロギング強化の例
Auditpol /set /subcategory:"File System" /success:enable /failure:enable上記のようにAuditpolコマンドを用いて、ファイルシステムのアクセスに関する監査を強化すると、どのユーザーがどのファイルへのアクセスに失敗しているかを詳細に記録できます。
5. グループポリシーやセキュリティソフトの影響をチェック
グループポリシー (GPO) の確認
- 「User Configuration -> Preferences -> Windows Settings -> Drive Maps」などでドライブマッピングが構成されている場合、意図しない権限設定が行われていないかチェックします。
- さらに、ソフトウェアの制限ポリシーやAppLockerの設定によってネットワーク経由の実行や書き込みが制限されていないかどうかも確認が必要です。
セキュリティソフト/ファイアウォールの設定
- サーバー側のウイルス対策ソフトが特定のドライブやネットワーク経路を監視対象としており、不正とみなしてブロックすることがあります。
- Windows Defenderや他社製ウイルス対策ソフトのリアルタイムスキャンの設定を一時的に無効化し、コピー操作が成功するかテストしてみましょう。
- ファイアウォールでSMBトラフィック(ポート445)に対して制限がかかっていないかも同時にチェックするとより確実です。
より高度な対処・トラブルシューティング
上記の基本的な対処法で問題が解決しない場合、さらに一歩踏み込んだ調査が必要になるかもしれません。
DFS(分散ファイルシステム)や名前空間を使用している場合
- DFSや名前空間を利用している環境では、UNCパスが物理フォルダに直接対応していないケースがあります。
- DFSルートやリンク先での権限設定やネームスペース設定の誤りが、特定の経路だけコピー動作をブロックすることもあります。
- DFS管理コンソールやWindows PowerShellの
Get-DfsnFolderコマンド等でリンク先の構成を詳細に確認しましょう。
SMBバージョンや暗号化設定の確認
- Windows Serverのバージョン差やクライアントの設定によって、SMB1/SMB2/SMB3のどれが使用されるかが変わってきます。
- グループポリシーまたはローカルポリシーでSMB1を無効化しているケース、SMB暗号化が有効化されているケースでは、クライアントとサーバー間で認証や暗号化がうまくいかず、コピーが失敗する可能性があります。
オフラインファイル (Offline Files) の影響
- クライアントPCがオフラインファイルを利用している場合、共有フォルダへのアクセスがキャッシュ経由になっており、不整合が起こることがあります。
- コントロールパネルの「同期センター」でオフラインファイルを一時的に無効にしてテストするか、キャッシュのリセットを検討してください。
トラブルシューティングのチェックリスト
以下のチェックリストを活用して、より体系的に原因を洗い出していきましょう。
- 権限の確認
- 共有権限とNTFS権限が正しく整合しているか？
- 所有者の設定は問題ないか？
- ログの確認
- サーバーのイベントビューアに「アクセス拒否」やエラーが記録されていないか？
- クライアント側のイベントログでも異常が報告されていないか？
- クライアント設定の見直し
- マッピングドライブを切断し、再マッピングを試したか？
- グループポリシーや資格情報マネージャーを確認したか？
- ネットワーク構成やファイアウォール
- SMBポート(445)が正しく通っているか？
- ウイルス対策ソフトのリアルタイムスキャンが干渉していないか？
- DFSやネームスペースが存在するか？
- DFSルートや名前空間に誤った設定がないか？
- SMBプロトコルバージョンの整合性
- SMB1/SMB2/SMB3が正しく有効になっているか？
まとめ：トラブル解消のためのポイント
最初に試すべきは、共有の再作成やクライアント側のドライブ再マッピングといったシンプルな対処です。これだけで多くのケースが改善します。その上で、NTFSと共有権限の整合性や、グループポリシー、ウイルス対策ソフト、イベントログのチェックを行うことで、原因を的確に突き止められます。
もし問題が依然として解決しないようであれば、より高度な機能（DFSやSMB暗号化設定、オフラインファイルなど）が影響している可能性も考慮してください。一つひとつ可能性を潰し込むことで、最終的には確実に対処法を見つけることができます。
コメント