Files.com 認証エラーを解決する — NetDrive

読了目安 6 分 troubleshooting files-com
Steve
SteveSenior Engineer
IP許可リスト制限、SSO強制、保存済み認証情報の失効が原因で起きる、NetDriveでのFiles.comサインイン失敗を解決します。

あるコンプライアンスチームは、監査担当者がWebアップローダーを使わずに署名済み文書をドライブレターへ直接保存できるよう、NetDrive経由でFiles.comアカウントをマウントしている。何週間も問題なく動いていたのに、ある朝すべてのワークステーションで「Authentication failed」と表示される——パスワードもNetDriveのビルドも同じで、Windows側で何も変えていない。原因はほぼ常にNetDriveの接続設定ではなく、Files.comアカウント側にある。

NetDrive drive manager showing Google Drive, S3 and pCloud mounted as drive lettersMounted clouds appearing as native drives in Windows File Explorer

Files.comをブラウザタブではなくドライブレターに

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

  • どのアプリの保存ダイアログからもFiles.comへ直接ファイルを保存
  • 大容量のコンプライアンスアーカイブでWebアップローダーを使わずに済む
  • 1つのドライブマネージャーで他のマウント済みクラウドと並べて使える
WindowsmacOS
NetDriveをダウンロード →

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

エラーを原因ごとに切り分ける

症状最も可能性の高い原因
Files.comのWebダッシュボードではパスワードが通るのにサインインが拒否されるアカウントでシングルサインオン(SSO)が強制されており、ユーザー名/パスワードの直接ログインではもう認証されない
オフィスでは動いていた接続が自宅や新しい場所で失敗するFiles.comアカウントのIP許可リストが、承認済みのネットワーク範囲にログインを制限している
管理者による変更の直後から認証情報が失敗するFiles.com側でのフォルダ権限やアカウントロールの変更により、既存のセッションが無効化された

NetDriveのドライブプロバイダー一覧に表示されるFiles.comプロバイダーのロゴ

解決策1: アカウントパスワードの代わりにAPIキーを使う

SSOが有効なFiles.comアカウントは、NetDriveのようなサードパーティクライアントからの直接パスワードを受け付けない——ログインは組織のIDプロバイダーを経由する必要があるが、NetDriveの接続ダイアログはそれを行わない。この場合にFiles.comが用意している回避策がAPIキーだ。Files.comアカウントのセキュリティまたはAPI設定で新しいキーを生成し、そのキーをパスワードの代わりにNetDriveのFiles.com接続フィールドで使う。

  1. ブラウザでFiles.comにサインインし、アカウントのAPIキー設定を開く。
  2. NetDriveがアクセスする必要のあるフォルダに範囲を限定した新しいキーを生成する。
  3. NetDrive → ドライブマネージャー でFiles.com接続を編集し、パスワード欄にAPIキーを貼り付ける。
  4. 接続 をクリックして再認証する。

設定済みのクラウドドライブを表示するNetDriveドライブマネージャー、Files.com接続の編集画面

解決策2: アカウントのIP許可リストを確認する

Files.comはセキュリティ制御として、特定のIP範囲にログインを制限する機能をサポートしている。この設定がアカウントで有効になっていると、記録されていないネットワーク——自宅オフィス、カフェ、新しいオフィスの場所——からのログイン試行は、パスワード間違いのときとNetDriveが表示する同じ一般的な認証エラーで拒否される。NetDrive側だけでは両者を見分ける方法がない。

Files.comアカウントを管理している人に、許可リストを確認してワークステーションの現在のIP範囲を追加するか、ISPやオフィスネットワークの変更後に範囲が変わっていないか確認するよう依頼する。範囲が追加されたら、他は何も変えずにNetDriveで接続を再試行する。

解決策3: 権限やロールの変更後に再認証する

管理者がアカウントのアクセスできるフォルダを絞り込んだり、Files.com上のロールを変更したりすると、アカウント自体は存在し続けパスワードも変わっていなくても、NetDriveが保持しているセッションが無効になることがある。既存の接続を編集するのではなく、NetDriveのドライブマネージャーから接続を完全に削除し、最初から追加し直す——こうすることで、古いセッショントークンを再利用するのではなく、現在の権限セットに基づく完全な再認証が強制される。

NetDriveで再認証後、ドライブが正常に接続されたことを確認する画面

それでも当てはまらない場合

APIキーを使用済みで、IP許可リストも問題ないことを確認済みで、接続も新しく追加し直したのに解決しない場合は、同じネットワーク上のブラウザからFiles.comアカウント自体にアクセスできるか確認する。Files.com側でアカウントが停止または一時的にロックされている場合も、NetDrive内ではまったく同じ認証エラーが発生し、接続ダイアログには認証情報の問題と区別できる手がかりが何もない。

まとめ

NetDriveでのFiles.com認証エラーのほとんどは、APIキーを必要とするSSO強制、現在のネットワークをブロックするIP許可リスト、またはアカウントの権限変更後に残る古いセッションが原因であり、NetDrive自体の設定が原因であることはめったにない。このトラブルシューティングの前提となる最初の接続については、NetDriveでWindowsにFiles.comをマウントするまたはNetDriveでmacOSにFiles.comをマウントするを参照。問題が起きているのが別のドライブでKoofrの場合は、Koofrの認証エラーにも似た2段階のパターンが載っている。

— Steve, NetDrive