共有フォルダとかファイルサーバってよく聞くけど、今はBoxやクラウドストレージがあるし使う機会あるんですか？
一方で、サーバ同士でファイルを受け渡す場合には、今でも共有フォルダが利用されることがあります。
例えば、以下のようなケースです。
・業務アプリケーションが出力したファイルを別サーバへ転送したい
・Webサーバで受信したファイルを別のサーバへ受け渡したい
・サーバ間でログファイルや帳票ファイルを受け渡したい
共有フォルダ自体は数分で作成できますが、
権限設定を誤るとアクセス障害やセキュリティ事故につながる可能性があります。
そこで今回は、共有フォルダにアクセスできない時に確認したいポイントを5つ紹介します。
- この記事を読むと、わかること
そもそも共有フォルダとは？
共有フォルダとは、ネットワーク経由で他のサーバやPCからアクセスできるように設定されたフォルダのことです。
例えば、
\192.168.196.xxx\share_folder
のような形式でアクセスします。
社内でのファイル共有だけでなく、サーバ同士でファイルを受け渡す用途でも利用されています。
ファイルサーバと共有フォルダの違い
ファイルサーバは、ファイルを保管・共有することを主な役割としたサーバです。
一方、共有フォルダはサーバ上で共有設定されたフォルダを指します。
そのため、
・ファイルサーバ上の共有フォルダ
だけでなく、
・Webサーバ上の共有フォルダ
・業務サーバ上の共有フォルダ
という構成も存在します。
共有フォルダを利用する場面
共有フォルダは以下のような場面で利用されます。
「\サーバ名\c$」ではダメなの？
Windowsには管理共有と呼ばれる仕組みがあり、別サーバへアクセスする際、以下のような形式でフォルダへアクセスできます。
\192.168.196.xxx\c$\folder
しかし、管理共有は管理者向けの機能です。
業務アプリケーションから利用する場合は、
・管理者権限が必要になる
・権限管理が難しい
・セキュリティ上好ましくない
といった理由から、専用の共有フォルダを作成して運用することが一般的です。
共有フォルダにアクセスできない時の確認ポイント5選
確認ポイント①：共有設定をしたからアクセスできるはず
共有フォルダを作成し、「このフォルダーを共有する」にチェックを入れたから、アクセスできると思っていないでしょうか？
実は共有設定をしただけではアクセスできない場合があります。
共有フォルダには、
の2種類が存在します。
どちらか片方だけ設定しても正常にアクセスできないことがあります。
共有フォルダへアクセスできない場合は、まず両方の権限を確認しましょう。
共有設定は確認していても、「セキュリティ（NTFS権限）」の設定を見落としているケースは少なくありません。
以下の画面のように、フォルダのプロパティから「セキュリティ」タブを開き、アクセスさせたいユーザーが登録されているか確認しましょう。
確認ポイント②：自分がアクセスできるからプログラムもアクセスできるはず
過去に私が実際にハマったポイントです。
Administratorでログインしている状態では共有フォルダへアクセスできました。
しかし、業務アプリケーションからファイルを保存しようとすると失敗していました。
原因を調査したところ、プログラムはIISのApplicationPoolIdentityで実行されていました。
つまり、
・自分のユーザー
と
・プログラムの実行ユーザー
が異なっていたのです。
共有フォルダへアクセスできない場合は、どのユーザー権限でプログラムが実行されているのかも確認しましょう。
「プログラムの実行ユーザーって何？」と思う方もいるかもしれません。
実は、プログラムは必ず何らかのユーザー権限で実行されています。
例えば、
などです。
私が実際に対応した事例では、以下のような状況でした。
| 実行方法 | 実行ユーザー | 結果 |
|---|---|---|
| エクスプローラーから手動アクセス | Administrator | 成功 |
| 業務アプリケーションからアクセス | ApplicationPoolIdentity | 失敗 |
Administratorでは問題なく共有フォルダへアクセスできていたため、最初はネットワークや共有フォルダ設定を疑っていました。
しかし調査を進めたところ、業務アプリケーションはIISの ApplicationPoolIdentity で実行されており、そのユーザーには共有フォルダへのアクセス権限が付与されていませんでした。
そこで専用のサービスアカウントを作成し、IISの実行ユーザーを変更したところ、正常にファイルを保存できるようになりました。
| 対応前 | 対応後 |
|---|---|
| ApplicationPoolIdentity | svc_api_app（サービスアカウント） |
| 共有フォルダ権限なし | 共有フォルダ権限あり |
| ファイル保存失敗 | ファイル保存成功 |
このように、
「自分はアクセスできる」＝「プログラムもアクセスできる」
とは限りません。
共有フォルダのトラブルが発生した場合は、実行ユーザーの確認も忘れずに行いましょう。
確認ポイント③：Pingが通るから共有フォルダも使えるはず
Pingが通るからといって、共有フォルダへアクセスできるとは限りません。
新人の頃はプロトコルやポート番号について詳しく知らないことも多く、
「サーバへPingが通るなら共有フォルダも問題なく利用できるだろう」
と思ってしまいがちです。
実際、PingはICMPという通信方式を利用しています。
一方で、共有フォルダへのアクセスはSMBというプロトコルを利用しており、デフォルトではTCP445番ポートの通信が必要になります。
そのため、
・Pingは成功する
・共有フォルダはアクセスできない
という状況も十分発生します。
共有フォルダへアクセスできない場合は、まずTCP445番ポートの疎通確認を行いましょう。
PowerShellで以下のコマンドを実行することで確認できます。
Test-NetConnection 192.168.xxx.xxx -Port 445
実行結果の
TcpTestSucceeded : True
となっていれば、TCP445番ポートでの通信は成功しています。
もし False の場合は、Windows Defender Firewall やネットワーク機器によって通信が遮断されている可能性があります。
確認ポイント④：権限を付与したから子フォルダも大丈夫なはず
共有フォルダへ権限を付与した場合でも、子フォルダへ継承されていないケースがあります。
例えば、
C:\share_folder
にはアクセスできるのに、
C:\share_folder\customer1
へアクセスできないことがあります。
特に途中で権限設定を変更している環境では注意が必要です。
共有フォルダ本体だけでなく、実際に利用するフォルダにも権限が付与されているか確認しましょう。
まとめ
今回は、共有フォルダにアクセスできない時の確認ポイントについて紹介しました。
共有フォルダのトラブルが発生した場合は、以下のポイントを確認してみましょう。
| 確認ポイント | 確認内容 |
|---|---|
| 共有設定 | フォルダが正しく共有されているか |
| 共有権限 | 対象ユーザーに必要な権限が付与されているか |
| NTFS権限 | セキュリティタブに対象ユーザーが登録されているか |
| SMB疎通 | TCP445番ポートで通信できるか |
| 実行ユーザー | プログラムがどのユーザーで実行されているか |
今回はWindows Serverの共有フォルダを例に紹介しましたが、Linux環境でも考え方は大きく変わりません。
利用するプロトコルや設定方法は異なる場合がありますが、
といった確認観点は共通しています。
トラブルが発生した際は設定内容だけを見るのではなく、「誰が」「どこから」「どの権限で」アクセスしているのかを意識すると原因を切り分けやすくなります。
今回紹介した内容を覚えるというよりも、「こういう観点で確認するんだな」と理解しておくことで、WindowsだけでなくLinuxやクラウド環境でも応用できると思います。
コメント