Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
WebDAV Mount Fails but Browser Works: Safe Checks
Ryan Foster
October 7, 2026· 11 min read
When a WebDAV mount fails but browser works, compare the actual WebDAV endpoint, credentials, and request method rather than treating the web login as a successful mount. Start with an authorized read-only directory listing, keep HTTPS verification enabled, and identify whether the failure belongs to transport, authentication, WebDAV handling, or a later file operation.
Key Takeaways:
- A browser session and a WebDAV client do not necessarily use the same endpoint or credentials.
- Reading a web page with GET does not validate a PROPFIND directory request.
- Inspect per-resource results; a 207 response is not a blanket success for every property.
- Compare routes only after endpoint and access requirements are confirmed.
Step 1: What endpoint matters when a WebDAV mount fails but browser works?
Obtain the exact HTTPS WebDAV address from the service's current documentation or administrator. A dashboard, share-preview page, and file collection can all belong to the same service while serving different purposes. Copying the browser's address bar after sign-in may select a human-facing page rather than the endpoint a file client needs.
Record the provider, client/version, operating system, endpoint role, intended collection, timestamp, and exact error. Keep private path segments out of public reports. Do not guess an endpoint from another provider's example or append a familiar WebDAV path without checking the owner's instructions.
Rclone's WebDAV backend requires an endpoint and credentials, with a vendor selection for services whose behavior differs.［1］ That configuration describes rclone; another mounting client may have its own limitations. Preserve the endpoint's hostname, scheme, and documented path instead of replacing them with a raw server IP.
Use the device and application baseline checks if several unrelated clients are failing. If the actual share uses SMB, follow the SMB-specific connection stages; a working SMB share does not validate WebDAV.
Step 2: What does browser success actually prove?
Describe what “works” means: a login page opened, you authenticated, a folder appeared, or a known file downloaded. These are different observations. The browser may use a stored cookie, a redirect through an identity provider, or a separate application interface that your WebDAV client never uses.
HTTP GET retrieves a representation; WebDAV PROPFIND retrieves properties for a resource and potentially its members. RFC 4918 defines PROPFIND and its Depth behavior.［2］ A web page returned by GET is therefore insufficient evidence for a directory listing that uses a different method.
The diagram is a protocol explanation, not a trace from the reader's account. It separates browser-session success from the WebDAV request and its response. Keep the observation tied to the actual method rather than labeling every failure “the website is down.”
If browser access succeeds but the client fails immediately, inspect endpoint and authentication before changing networks. If both fail before reaching the server, a shared transport problem becomes more plausible. If the client can list but cannot write, preserve the successful listing and investigate the specific write operation.
Step 3: Does this client support the required WebDAV authentication?
Check whether the service supports a WebDAV client password, a provider-issued app password, or another documented authentication mechanism. Do not assume that the website's interactive login password will work in every client, especially when an organization uses single sign-on or multi-factor authentication.
Create an app password only through the provider's official account flow if its documentation requires one. Give it the minimum relevant access, keep it private, and revoke it through the same account interface when no longer needed. Do not disable multi-factor authentication just to make a legacy mounting client accept a password.
WinSCP's Login dialog exposes the connection protocol and endpoint settings.［3］ The official screenshot below illustrates that dialog on Windows; it is not a configured or validated WebDAV account. Choose WebDAV in your version and enter only the provider's documented HTTPS configuration.
If the client cannot implement the service's supported authentication, stop and choose a provider-supported client or ask the administrator. Do not paste browser cookies into configuration or reuse an unrelated application's token. A browser login remaining valid while the file client receives an authentication rejection is an access-model distinction, not evidence that a VPN is needed.
Step 4: Which response or failed stage matters?
Capture the first client error and, where available, the response for the actual WebDAV request. Distinguish no connection, a TLS error, an HTTP response, and a file-operation failure. A timeout without any response is different from a prompt followed by a status code.
| Observation | What to investigate | What to avoid |
|---|---|---|
| No connection or response | Correct endpoint, required proxy, allowed path | Changing account credentials blindly |
| TLS identity or trust error | Hostname, certificate, clock, approved trust policy | Disabling certificate verification |
| 401 authentication challenge/rejection | Supported client credentials and authentication | Reusing cookies from a browser |
| 403 denied request | Service policy, path permission, depth restrictions | Repeated guesses at privileged paths |
| 405 method not allowed | Wrong endpoint or method handling | Treating a web login as PROPFIND support |
| 207 Multi-Status | Individual resource/property statuses | Treating the outer status as universal success |
| 423 Locked on a relevant operation | Server's lock state and ownership | Forcing deletion of locks or files |
RFC 4918 describes Multi-Status responses and the Locked status. Its PROPFIND section also allows a server to reject infinite-depth requests for performance and security reasons.［2］ Read the requested depth and individual results rather than concluding that every denial indicates invalid credentials.
A lock error on a later write does not automatically explain an earlier read-only listing failure. Record the operation that produced it. Similarly, a property-level error in a 207 result need not mean that every listed resource failed. Ask the provider how the specific client interprets that result.
Step 5: Is a proxy or redirect changing the request?
Compare the browser's network configuration with the mounting client's documented proxy behavior. A browser may successfully use an organization sign-in flow while a file client receives a redirected login page or cannot authenticate to the required proxy. Keep the process's actual execution location clear: your laptop's browser is not a test of a WebDAV job on a remote server.
Rclone documents HTTP proxy support for its HTTP-based services.［4］ Inspect the relevant environment and client settings locally without printing credentials. An obsolete proxy can explain differences, but a required corporate proxy must be corrected with its owner rather than removed as a generic fix.
If the client reports a redirect, obtain the intended WebDAV endpoint from the service owner. Do not build an automatic chain that forwards credentials to arbitrary hosts. A redirected HTML sign-in page is not a WebDAV collection, even if the page looks familiar.
For certificate warnings, follow the certificate diagnosis guide. Keep HTTPS and normal identity checks. Do not enable cleartext Basic authentication, import an untrusted certificate, or lower client security because the browser appears to work.
Step 6: Can you list one permitted collection safely?
Use the provider-supported client to list a small collection you are authorized to read. Do not start with a filesystem-wide mount or an unlimited recursive scan. A successful read of the intended collection is a narrower and more interpretable test than opening every folder in an account.
For an already configured, authorized rclone WebDAV remote, a bounded directory listing can be used:
rclone lsd davremote:approved-test-parent --max-depth 1
Replace the remote and path with your own documented configuration. Rclone's lsd lists directories and supports depth controls.［5］ If the collection has no child directories, a successful command may produce no rows; inspect the result and actual collection before calling that an error.
After listing succeeds, download one permitted small file into a new local test location and inspect its known contents. Keep writes, renames, synchronization, and lock changes out of this first test. A client mount may have additional filesystem behavior, so report a successful listing as a successful listing, not as proof of every mounted operation.
The Zotero-specific connection workflow covers its attachment verification and library model. Use that page when Zotero is the client rather than resetting a research library through a generic WebDAV procedure. For desktop synchronization, use the separate cloud-sync checklist.
Step 7: Does an authorized network comparison change the listing?
This branch applies after the service confirms WebDAV support and valid credentials, when the evidence still points to the connection path. Keep the client, endpoint, collection, authentication, and requested operation fixed. Where allowed, compare one direct listing with one listing through an alternative route.
AethoVPN can supply that second outbound path on the computer issuing the WebDAV request. Use the official Windows installer, or the .deb client on supported Debian/Ubuntu x64, with Pro or Premium for desktop access; Mac uses the website's configuration guide with the same eligible tiers. Enable global mode, choose a currently available nearby position, and repeat the same read-only collection listing. Endpoint methods, app-password validity, permissions, and lock ownership remain service-side matters; start a 3-day free Pro trial to compare the connection, available once per user and beginning at registration.
Record the first response, listing outcome, and timestamp for each path. If the same 401 or 405 remains, resolve that condition instead of rotating exits. If the collection lists only through one path, preserve that specific observation for the provider and network owner without claiming that all mounts or transfers are fixed.
Do not use this comparison to reach a private corporate collection that requires an enterprise route, an approved device, or a fixed source address. If a mandated connection cannot be changed, ask the administrator for a supported comparison. The rclone retry workflow explains how to keep backend errors separate if rclone is producing repeated attempts.
Step 8: What should remain in the incident record?
Keep the provider/client/version, endpoint role, sanitized path, authentication type, actual method if known, response status, per-resource errors, timestamp, and approved comparison results. State whether browser success meant login, listing, or file download. This makes the distinction actionable for the service owner.
Review diagnostics before sharing. Remove passwords, authorization headers, cookies, tokens, private filenames, and sensitive collection paths. Send only what the provider requests through an approved channel, and preserve the full original privately if further analysis is needed.
Retain the unchanged working configuration until the owner confirms a correction. Do not delete locks, rebuild an account, or mass-remount unrelated collections to force a green status. After a supported fix, repeat the same read-only test and then verify the particular operation that originally failed.
Summary
- Obtain the actual HTTPS WebDAV endpoint and supported client authentication.
- Separate browser GET from WebDAV requests and individual response results.
- Verify one permitted listing before attempting writes.
- Compare paths only for a real transport branch and preserve security checks.
FAQ
Does browser access prove that WebDAV is enabled?
The browser may open a separate web application with different methods and authentication. Confirm the service's WebDAV endpoint and a successful client request before treating it as enabled.［1］［2］
Must I disable multi-factor authentication for a mount?
Keep multi-factor authentication. Use a documented app password or another supported client mechanism when required; an incompatible client should not dictate weaker account security.
Is every 207 response a successful mount?
A Multi-Status response contains individual results that must be interpreted. Inspect those results and the requested operation; the outer status alone does not establish complete success.［2］
Why might PROPFIND fail when GET works?
The endpoint, intermediary, or permission may handle the methods differently. GET success validates a different operation from retrieving a collection's WebDAV properties.［2］
Should I remove a server lock to reconnect?
Do not remove locks without the service owner's recovery procedure. Identify the operation and lock owner first; forcing a lock change can interfere with another writer.
Can a changed IP correct an app password?
A different route does not replace the service's credential requirements. Resolve an invalid app password through the provider's account flow before continuing connection comparisons.
Why does a successful directory list show no folders?
The collection may contain no subdirectories. Check the exit result, intended path, and supported listing semantics rather than treating absent directory rows as a transport failure.［5］
Disclaimer: Use authorized collections and provider-supported clients. This workflow does not authorize weakening HTTPS, changing access policy, or deleting locks or account data.
Sources
- Rclone — WebDAV — https://rclone.org/webdav/
- IETF — RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) — https://www.rfc-editor.org/rfc/rfc4918
- WinSCP — Login Dialog — https://winscp.net/eng/docs/ui_login
- Rclone — Documentation — https://rclone.org/docs/
- Rclone — rclone lsd — https://rclone.org/commands/rclone_lsd/
Sources checked 7 October 2026.
