Azure File Storage の認証エラーを解決する — NetDrive

あるIT管理者は、Windows Server RDSホスト上でドライブレターとしてマウントした5つのAzure File Storage共有を管理しています——部署ごとに1つずつ、それぞれ古いオンプレミスのファイルサーバーから移行したものです。月曜の朝、Finance共有だけがNetDriveで認証エラーを起こし、残り4つは正常に再接続します。金曜以降マウント設定を変えていないなら、たいていはNetDriveではなく、認証情報か共有自体が変わったということです。

Azure File Storage を永続的なドライブレターとしてマウント

NetDrive を使えば Google Drive、OneDrive、S3、SFTP、WebDAV などが Windows と macOS でネイティブドライブとして表示されます — 同期も、まるごとダウンロードも不要です。

• アカウントキーまたはスコープを絞ったSASトークンで接続
• 起動時の自動マウントでログイン前から共有を準備
• チームライセンスで管理者が全マシンに認証情報を配布

WindowsmacOS

NetDrive をダウンロード →

無料トライアル。永久ライセンスとサブスクリプションプランあり。

Azure File Storage と Azure Blob——同じエラー、違う原因

NetDriveはAzure File StorageとAzure Blob Storageを別々の接続タイプとして扱っており、認証失敗の原因も少しずつ異なる場所にあります。Blob Storageはコンテナを指し、File Storageはストレージアカウント配下にある名前付きのSMB形式のファイル共有を指します。File Storageベースのドライブが正しく再接続するには3つの値が必要です——ストレージアカウント名、認証情報（アカウントキーまたはSASトークン）、そして正確な共有名——なので「先週まで動いていたのに今日は動かない」という失敗が起こり得る場所は3つあります。

チェック1：SASトークンの期限切れ、またはアカウントキーのローテーション

最も多い原因であり、最も早く除外できる原因でもあります。

1. Azure Portalで問題のドライブの背後にあるストレージアカウントを開き、どの認証情報タイプで設定されているかを確認します。
2. SASトークンの場合：Security + networking → Shared access signature に移動し、Expiry date がまだ過ぎていないか確認します。設定時に90日の有効期限で生成されたトークンは、3か月後に何の予告もなく静かに機能しなくなります。
3. アカウントキーの場合：Security + networking → Access keys に移動し、key1 または key2 が最近再生成されていないか確認します——別の管理者が定期的な衛生管理として認証情報をローテーションし、他の4つのサービスがまだ古い値を参照していることに気づいていない、というケースがよくあります。
4. File サービスにスコープを絞った新しいSASトークン（最低でも Read、Write、List、Create、Delete 権限）を生成するか、現在のアカウントキーをコピーします。
5. NetDriveを開き → Drive Managerで該当ドライブの歯車アイコンをクリックして接続設定を開き、新しい認証情報を貼り付けて Save をクリックします。

チェック2：ストレージアカウントのファイアウォールルール

認証情報に問題がないのにドライブが認証されない場合、次に確認すべきはストレージアカウントのネットワークルールです。

1. Azure Portalで、そのストレージアカウントの Networking → Firewalls and virtual networks を開きます。
2. All networks ではなく Enabled from selected virtual networks and IP addresses に設定されている場合、Azureは認証情報を評価する前に接続試行そのものを拒否します——これはNetDrive側から見ると、キーが間違っている場合とまったく同じに見えます。
3. マシンの現在のグローバルIPを確認して許可範囲に追加するか、その共有にIPベースの制限が不要であればルールを緩和します。

動的IPを使う自宅回線や支社回線のマシンは、ここで繰り返し問題を起こしがちです。ルールを追加した時点では正しかったものの、その後ISPが別のアドレスを割り当てたというケースです。

チェック3：共有の名前が変更または削除された

Blobコンテナとは異なり、File Storage共有は同じストレージアカウント配下であれば、ストレージアカウント自体の認証情報を変えずに名前変更、削除、再作成が可能です——つまりアカウントキーやSASトークンは問題なく認証されるのに、NetDriveが元々指していた共有を見つけられない、という状態になります。Azure Portalでそのストレージアカウントの Data storage → File shares に移動し、共有名が大文字小文字も含めてNetDriveの接続設定に入力されているものと完全に一致しているか確認します。削除後に再作成された共有であれば、他の認証情報が変わっていなくても、NetDrive側の共有名フィールドを更新してください。

修正の確認

認証情報、ファイアウォールルール、または共有名を更新したら、ドライブを再接続し、ドライブ一覧に「Connected」と表示されるだけでなく、実際にファイルを提供しているかを確認します。

エクスプローラーでドライブを開き、見覚えのあるファイルが入ったフォルダーを一覧表示します。一覧が表示され、ファイルがエラーなく開けば、認証情報、ネットワークパス、共有名のすべてが正しいということです。

まとめ

NetDriveでのAzure File Storage認証失敗は、元の設定のタイプミスよりも、期限切れのSASトークン、ローテーションされたアカウントキー、ストレージのファイアウォールルール、あるいは名前が変更された共有に起因することのほうがはるかに多いです——確認が早く済む認証情報から先にチェックし、その後ネットワークを確認しましょう。初回接続の手順についてはNetDriveでWindowsにAzure File Storageをマウントするを、問題のドライブが実際にはファイル共有ではなくBlobコンテナを使っている場合はAzure Blob認証エラーの解決で同等のケースを扱っています。

— Casey, NetDrive