Skip to main content

Troubleshooting WebDAV

A WebDAV problem may come from the network connection, account access, or the client's handling of a file operation. The same Files.com site can behave differently in two clients because operating systems impose their own limits and use WebDAV differently. Identifying that distinction helps users and IT administrators choose a useful next check.

Start with the failed operation and the client's exact error message. Confirm the connection settings, then establish whether the client can reach the server and sign in. A successful login followed by a failed upload calls for a different investigation from a connection that cannot be established at all.

If a previously working connection fails, compare recent changes to the client, network, credentials, and site settings. After an interrupted transfer, check the destination before letting downstream work consume the file. Include the error and time of the failed operation when requesting support, so the reported behavior can be matched to the relevant activity.

For a drive mapped with the Windows client, check its service, transfer, path, and reconnection settings alongside these network and account checks.

Local Network / Firewall Issues

Secure WebDAV (also referred to as WebDAVS or WebDAV over SSL) is occasionally blocked by firewalls. Firewall changes can introduce new blocks that didn't previously exist.

Files.com does not support or allow insecure plain WebDAV.

Find a set of settings that works for a particular network or firewall. The right settings vary across your user base depending on which corporate or network firewalls each user sits behind.

Manually Whitelisted IP Addresses

If you have manually whitelisted IP addresses anywhere, verify that all of the appropriate IPs are whitelisted, not just some of them.

If your site uses a custom domain, you have two dedicated IPs that need to be whitelisted in your firewall. You can find your dedicated IPs on the Firewall page of your site. With a custom domain, you also need to connect to that domain, not to [your_subdomain].files.com.

If you do not have a custom domain, whitelist the Files.com owned IP range. A single firewall rule covering the range allows all Files.com traffic.

Consider an IP Whitelist

If you have not whitelisted IP addresses, your firewall administrator may require this for WebDAV traffic. Submit a request to your network or firewall administrator to allow WebDAV port 443 traffic to the Files.com owned IP range.

WebDAV Login Issues

If a username-and-password login fails over WebDAV, try signing in to the Files.com web interface with the same account. If web sign-in also fails, resolve that account or credential problem before changing the WebDAV client configuration.

If web sign-in prompts for a password change, complete it and update the password saved in the WebDAV client. Review the account preparation requirements before reconnecting.

Two-Factor Authentication

If 2FA is required and the web interface prompts for initial setup, complete that setup before retrying WebDAV. Then check the supported WebDAV 2FA methods and password format. Successful web sign-in does not establish that the configured second-factor method works with WebDAV.

For everyday desktop access with 2FA, use the Desktop App, which supports browser-based sign-in without requiring the WebDAV password-and-code format.

Partially Uploaded Files

If a file uploaded through WebDAV is empty, shorter than expected, or fails downstream processing, check the producing client's transfer status. Compare the saved file's size and contents with the completed source file. A file being visible at its destination does not confirm that the upload finished; some clients save incrementally as described in WebDAV upload completion.

If the client reports an interrupted or failed transfer, resolve the client or connection error and resume or retry the upload. Confirm completion in the client and verify the saved file before submitting it for processing again.

Processing Began Before Upload Completion

Compare the client's completion time with the Automation or Sync run and the file activity for the affected path. Check whether a transfer, GPG operation, or automatic rename acted on the file while the client was still writing it. A decryption or processing error alone does not prove that the input was incomplete.

If processing began too early, exclude the active upload location from downstream work and configure a completed-file handoff. After the complete file is available, inspect any partial output already delivered and follow the receiving workflow's recovery procedure before rerunning the affected step. Adding a fixed delay does not confirm that future uploads will be complete.

If the client confirms a completed upload but the saved file is still incomplete, or the run logs do not explain the result, contact Support with the path, transfer time, client version, and relevant run details.