I had a Windows desktop client that had been offline for several months while the same Nextcloud tree was reorganized from another Windows machine.
Environment
-
Server: Nextcloud Hub 25 Autumn, version
32.0.3 -
Desktop: Windows 10
10.0.19045.6466, Nextcloud Desktop Client4.0.4 (Windows) -
Laptop: Windows, Nextcloud Desktop Client
34.0.2 -
Both desktop clients report that they are up to date.
The large difference between the two desktop client version numbers is not a typo. These are the versions currently displayed by each client.
What happened
While the desktop was offline, I reorganized parts of the synced folder structure from the laptop.
When I started using the desktop again, its local copy still contained the older structure. Nextcloud repeatedly reported “Access is denied” while trying to reconcile one of the old local folders with the current server copy.
The server/web copy itself appeared correct, and I could not find anything useful corresponding to the failure in the server logs.
The affected local folder contained many .ttf and .otf font files.
What I investigated locally
Manual deletion of the stale local folder failed on numerous font files with:
Access is denied.
I then tried the following:
-
Terminated
explorer.exe -
Recursively took ownership of the affected directory with
takeown -
Recursively granted my Windows account Full Control with
icacls -
icaclssuccessfully processed 167 files with 0 failures -
Cleared read-only, system and hidden attributes
-
Terminated two running
fontdrvhost.exeprocesses -
Tried deleting an individual
.ttffile directly
Despite all of that, the font files still returned:
Access is denied.
So simply lacking ownership or NTFS permissions did not appear to explain the problem.
I am not claiming that Nextcloud caused the files to be locked. The lock may have originated from Windows itself, font-management software, or another local process.
What eventually happened
After a later full Windows restart, Nextcloud successfully reconciled the desktop folder structure with the current server/laptop structure.
The interesting part is that this was not the first restart the desktop had received recently, although by this point I had also already corrected ownership and ACLs on the affected directory.
Because of that, I cannot conclusively identify which factor finally allowed the reconciliation to complete.
Why I am posting this
What I think could be improved is the desktop client’s diagnostics for local filesystem failures.
The error essentially told me that access was denied and suggested checking logs, but it did not make clear that:
-
the failure appeared to be local to the Windows filesystem
-
the server itself appeared healthy
-
a local delete/rename/reconciliation operation was failing
-
checking server logs was unlikely to explain the problem
-
the underlying Windows error or failed filesystem operation was not exposed in a useful way
Something more explicit, for example:
Windows denied access to a local file while applying a remote change.
The file may be in use by another application or protected by local permissions.
would have saved a significant amount of troubleshooting time.
It would also be useful if the client exposed:
-
the exact local operation that failed, such as delete, rename, move or replace
-
the affected local path
-
the underlying Windows/Win32 error code where possible
-
a clear distinction between a local filesystem/client error and a server/WebDAV error
-
a direct route to the relevant desktop-client log or debug archive
There is a possibly related GitHub issue, #7100, involving Access denied during removal of stale local folders, but that case appears to involve Virtual Files and empty directories, so it does not seem to match this reproduction closely enough to treat it as the same issue.
Is this expected behavior for the Windows desktop client, or would better diagnostics for this type of local filesystem failure be considered worthwhile?