Nextcloud desktop not syncing while the website opens usually means the desktop transfer needs a separate check. Protect local changes, inspect the account and folder status, and test one harmless file before changing credentials or rebuilding anything.

Key Takeaways:

A working web login does not prove that the desktop client's WebDAV requests succeed.

Record the failing account, folder, file, and error before making a change.

Keep unsent edits outside the synchronized tree before any repair with overwrite risk.

Judge recovery by a completed client transfer and the correct server-side file version.

Why is Nextcloud desktop not syncing when the website works?

The website and desktop application share a service, but they do not perform identical requests. A browser session can still work when desktop authorization has expired, a folder is paused, or a reverse proxy handles WebDAV incorrectly. Nextcloud's troubleshooting documentation specifically separates web access from WebDAV functionality.［1］

Start with a decision table rather than a reset. The distinctions below are diagnostic recommendations, not a claim that one particular error has a single cause. If several applications fail, use the system-wide application troubleshooting branches before changing only Nextcloud.

Observation	Check first	Result that changes the next action
Account asks you to sign in again	Correct server and approved authorization	Account reconnects without changing folder mapping
Folder is paused or excluded	Selected synchronization folders	Intended folder is active and selected
Certificate or authorization error	Server certificate and account access	Administrator resolves the explicit rejection
Website works but every client fails	WebDAV and reverse proxy configuration	Administrator confirms desktop requests reach the service
One file times out on one network	Same file on an approved alternative path	Client transfer and server file both complete

Step 1: How do you protect files waiting to upload?

Stop editing the affected files and close the application holding them open. Note which items have unsent changes, then copy their current local contents to a separate, nonsynchronized backup location. Open the backup to make sure it contains the work you expect; copying an online-only placeholder is not a verified backup.

Do not delete the synchronization directory or reconnect it to an empty folder. Removing and recreating an account can change which local and remote files are reconciled, so it is not an appropriate first diagnostic step.

Record the desktop client version, operating system, affected folder, error text, and approximate failure time. Note whether the problem began after a password change, client update, network change, or server maintenance.

Which file should you use for the test?

Choose a small, nonconfidential file that you are authorized to upload, with a unique filename and recognizable contents. Use an ordinary supported filename and a destination inside the folder already selected for synchronization. Do not use a production document that somebody else is editing.

Keep this file separate from the backup of important work. A successful test demonstrates that this particular account, path, and transfer worked; it does not prove that every large file or excluded item will synchronize.

Step 2: Is the client using the right server and authorization?

Open the account view in the desktop client. Compare its server address with the service your organization or provider has instructed you to use, including any deployment subpath. A similarly named server or an old account can make the webpage comparison misleading.

Check whether the account is connected and whether the relevant folder is paused, deselected, or reporting a local error. The official client guide describes the account and synchronization controls; use the labels in your installed version rather than assuming that a screenshot from another release is identical.［2］

If the client requests authorization, follow the server's approved login flow. A browser's existing session does not mean its password or authorization can simply be copied into the desktop application. Where the deployment requires an application password or administrator approval, obtain it through that deployment's documented process.

What should stay unchanged during authorization repair?

Keep the same account, remote folder, and local folder unless the administrator explicitly requires a migration. Do not expose passwords, app passwords, session cookies, or authorization links in a support post.

A certificate rejection belongs to the certificate or trust configuration branch. Check the server name and ask the administrator to supply a valid, appropriate certificate; never disable TLS verification to make a transfer appear successful. An unauthorized response is also different from a timeout: changing the network does not grant permission.

Step 3: What does the Nextcloud WebDAV connection reveal?

A Nextcloud WebDAV connection carries desktop file operations. Therefore, loading the website is only an initial connectivity check; it does not test every operation the client needs. If browser access works but multiple desktop clients fail, Nextcloud advises checking the WebDAV service and server setup.［1］

Read the account error and the failing item's status first. Distinguish name-resolution failure, connection timeout, certificate rejection, authorization rejection, and a server response. Keep the actual text rather than rewriting all of them as “offline.”

If your provider documents the WebDAV address, ask its administrator to verify that endpoint and the relevant desktop requests. A page opening or an authentication prompt is not evidence that uploads, file listings, and other required operations all succeed.

How do you separate a server problem from a device problem?

Ask whether another authorized client using the same deployment has the same failure, without sharing credentials. Several clients failing at the same operation strengthens the case for administrator investigation. One failing device instead directs attention toward that device's account state, local folder, proxy, and network.

The WebDAV-specific failure checklist explains the general distinction between browser access and protocol operations. Keep this article's test inside the Nextcloud desktop client, so a successful unrelated mount is not substituted for synchronization.

For Windows, compare the configured system proxy and its scope with your organization's instructions. Record whether an explicit client proxy is also configured. Do not remove a required corporate proxy or trusted security configuration merely because the webpage takes a different route.

Step 4: Can the same test file finish on an approved path?

Only enter the network comparison after authorization, selected folders, and local storage are plausible, and the observed failure points toward reachability or timeout. If the server is accessible only through an organization network or enterprise VPN, keep using that approved access method. A consumer VPN is not an entrance to a private deployment.

First retry the small test file on the original connection and record the result. Keep the account, server, client version, file, and target folder unchanged. Wait for the client to finish or display its explicit error; a webpage refresh cannot replace this observation.

For a publicly reachable server you are permitted to access, AethoVPN can provide a second network path for that same desktop WebDAV transfer. On Windows, use the official installer; Linux support is limited to Debian/Ubuntu x64 through the .deb package. On Mac, obtain the configuration through the official setup guide and connect with a VPN client using Pro or Premium. Enable global mode for the comparison, select an available nearby location, and retry the identified file without changing its destination.

Verify the VPN connection using a task-based connection check, then return to Nextcloud. Require both a completed transfer in the client and the expected contents or version in the server's Files view. A connected tunnel alone is not the result you are testing.

This comparison cannot repair invalid authorization, a broken WebDAV reverse proxy, insufficient storage, or a server outage. If the VPN path also fails, restore the original connection and keep the evidence instead of repeatedly changing locations. If you need to try this public-server comparison, start the three-day Pro trial; the trial is available once per new user.

How much does a successful comparison prove?

Success on the second path is evidence of a path-dependent difference, not a complete diagnosis of the first network. Report which transfer succeeded and under which conditions. It does not establish whether DNS, a proxy, routing, or another component was responsible, and it does not guarantee that the original large transfer will now finish.

After the test, resume normal synchronization carefully and check the previously blocked items individually. Keep the independent backup until the real work appears correctly on the server. Do not delete conflicting copies simply to obtain a green status icon.

Step 5: When should an administrator take over?

Escalate when multiple clients fail, the service rejects authorization or certificates, server responses recur, or only larger transfers fail despite a successful small test. The official troubleshooting page contains server and logging guidance, but its latest route can move between documentation versions. Verify advice against your installed client and server before changing configuration.［1］

Send the administrator a concise sequence: client version, server version if known, failure time, operation, redacted error, test file details, and the two path results. Keep account names, private paths, tokens, and confidential filenames out of public channels. Use a secure channel for logs the administrator actually needs.

Ask for a check of the service's WebDAV handling, authorization backend, reverse proxy, and relevant server logs.

If the small file works but the original does not, return to its specific status: size, filename, selected folder, permissions, quota, and local write conditions. Stop broad network experiments once an explicit nonnetwork failure is identified. Leave the existing synchronization tree intact while the responsible owner investigates.

Summary

Protect local edits before changing account or synchronization configuration.
Separate website access, desktop authorization, WebDAV operations, and individual file status.
Compare one authorized file with only the network path changed.
Confirm the completed client transfer and correct server copy before calling it recovered.

FAQ

Why can I sign in on the website while the client stays offline?

The browser session and desktop authorization are separate, and the client also performs WebDAV operations. Check the desktop account's actual error and folder state rather than assuming that a successful web login proves synchronization access.

Should I delete the local folder to restart synchronization?

No. Preserve unsent edits and the current mapping before considering destructive repairs. Recreating a directory changes the reconciliation context and can expose files to overwrite or deletion; involve the administrator when a reset is actually required.

Does a WebDAV authentication prompt mean uploads work?

No. A prompt shows that one request reached an authentication stage, not that the desktop client's authorized transfer succeeded. Verify the client operation itself and the expected server-side contents or version.

What should I check when the Nextcloud client offline message persists?

Record the exact message, confirm the configured account and server, and inspect selected folders and local errors. Certificate or authorization failures need their own repair; only a reachability or timeout branch justifies a controlled path comparison.

Can I use the VPN comparison for an internal company server?

Only use the access path your organization authorizes for that server. A consumer VPN does not supply company network membership or private endpoint access, and an administrator must handle policy or routing restrictions.

What counts as a recovered test transfer?

The desktop client must finish the identified file and the server must contain the expected version or contents. A green connection indicator, changed address, or website loading by itself is insufficient evidence.

What information helps support without exposing secrets?

Share versions, the failure time, operation, redacted error, and controlled test outcomes. Remove credentials, tokens, private filenames, and confidential paths, and provide requested logs only through the administrator's approved secure channel.

Sources

Nextcloud — Troubleshooting — https://docs.nextcloud.com/server/latest/admin_manual/desktop/troubleshooting.html
Nextcloud — Using the Client — https://docs.nextcloud.com/server/latest/user_manual/en/desktop/usage.html

Sources checked 7 October 2026.

Nextcloud Desktop Not Syncing: Check WebDAV Access