Fix Files.com Authentication Errors — NetDrive
Troubleshoot Files.com sign-in failures in NetDrive caused by IP allowlist restrictions, SSO enforcement, and stale saved credentials.
A compliance team mounts its Files.com account through NetDrive so auditors can drop signed documents straight into a drive letter instead of the web uploader. It works for weeks, then one morning every workstation shows “Authentication failed” — same password, same NetDrive build, nothing changed on the Windows side. The cause almost always sits on the Files.com account, not in NetDrive’s connection settings.
Give Files.com a drive letter, not a browser tab
NetDrive lets Google Drive, OneDrive, S3, SFTP, WebDAV and more appear as native drives on Windows and macOS — no syncing, no full downloads.
- Drop files into Files.com from any app's Save dialog
- Skip the web uploader for large compliance archives
- Works alongside other mounted clouds in one drive manager
Free trial. Lifetime and subscription plans available.
Map the Error to a Cause
| Symptom | Most likely cause |
|---|---|
| Sign-in rejected even though the password works on the Files.com web dashboard | Single sign-on (SSO) is enforced on the account, so a direct username/password login no longer authenticates |
| A connection that worked from the office fails from home or a new location | An IP allowlist on the Files.com account is restricting logins to approved network ranges |
| Credentials fail right after an admin change | A folder permission or account role change on Files.com’s side invalidated the existing session |
Fix 1: Use an API Key Instead of the Account Password
Files.com accounts with SSO enabled won’t accept a direct password from a third-party client like NetDrive — the login has to go through the organization’s identity provider, which NetDrive’s connection dialog doesn’t do. The workaround Files.com provides for this case is an API key: generate one from the Files.com account’s security or API settings, then use that key in place of the password in NetDrive’s Files.com connection fields.
- Sign in to Files.com through a browser and open the account’s API key settings.
- Generate a new key scoped to the folders NetDrive needs to access.
- In NetDrive → Drive Manager, edit the Files.com connection and paste the API key into the password field.
- Click Connect to re-authenticate.
Fix 2: Check the Account’s IP Allowlist
Files.com supports restricting sign-ins to specific IP ranges as a security control. If that setting is turned on for the account, a login attempt from an untracked network — a home office, a coffee shop, a new office location — gets rejected with the same generic authentication error NetDrive shows for a bad password. There’s no way to tell the two apart from NetDrive’s side alone.
Ask whoever administers the Files.com account to check the allowlist and add the workstation’s current IP range, or to confirm the range hasn’t changed after an ISP or office network update. Once the range is added, retry the connection in NetDrive without changing anything else.
Fix 3: Re-Authenticate After a Permission or Role Change
An admin narrowing which folders an account can reach, or changing its role on Files.com, can invalidate the session NetDrive is holding even though the account itself still exists and the password hasn’t changed. Remove the connection from NetDrive’s Drive Manager entirely and re-add it from scratch, rather than editing the existing entry — this forces a full re-authentication against the current permission set instead of reusing a stale session token.
When None of These Apply
If an API key is in use, the IP allowlist is confirmed clear, and the connection was freshly re-added, check whether the Files.com account itself is reachable from a browser on the same network. A suspended account or a temporary lock from Files.com’s side produces the exact same authentication failure inside NetDrive, with nothing in the connection dialog to distinguish it from a credentials problem.
Wrap-up
Most Files.com authentication failures in NetDrive trace back to SSO enforcement needing an API key, an IP allowlist blocking the current network, or a stale session after a permission change on the account — rarely a NetDrive setting itself. For the initial connection this troubleshooting builds on, see Mount Files.com on Windows with NetDrive or Mount Files.com on macOS with NetDrive. A similar two-factor pattern shows up in Koofr’s authentication errors if that’s the other drive giving trouble.
— Steve, NetDrive