I’m running into a persistent “WindowsError 5: Access Denied” when the NextCloud desktop client tries to download files from a read-only shared folder to my local sync directory.
Setup:
OS: Windows (desktop client)
NextCloud version:32.0.9 managed Service
Desktop client version: 33.0.7
Local sync path:C:\_My\Cloud
What works:
Syncing folders where my NextCloud account has read AND write permissions works flawlessly (~1 GB synced without errors).
What fails:
As soon as the client begins downloading files from a read-only shared folder (shared by another NextCloud account with read-only permissions), I get: WindowsError: 5: Zugriff verweigert (Access Denied)
What I’ve already tried:
Reset NTFS permissions and explicitly granted Full Control to all local users on the sync directory (icacls /reset /T + icacls /grant)
Verified Windows Defender Controlled Folder Access is disabled (EnableControlledFolderAccess = 0)
No third-party antivirus running
Observation: The error appears to occur only when the client attempts to write downloaded files locally from a server-side read-only share — not during the initial folder scan/metadata phase.
Question: Is this a known issue with read-only shared folders? Could the NextCloud client be applying read-only attributes locally that reflect the server-side permissions, thereby preventing itself from writing the downloaded files to disk?
Answer: Yes it is, and your own guess is exactly right, so you can stop fighting the permissions on your side.
For a read-only share the desktop client does not just set the Windows read-only attribute, it writes an actual deny-write entry into the folder’s ACL, an ACCESS_DENIED_ACE against the built-in Users group that takes away FILE_WRITE_DATA and FILE_APPEND_DATA among others. On a folder those two are exactly “create a new file” and “create a new subfolder”, so the moment the client has finished downloading and wants to write the file into that folder, Windows denies it, and you get WindowsError 5 in the writing phase rather than during the scan. The client is locking itself out.
That also explains why your icacls full control changed nothing. On Windows a deny entry always wins over any allow entry, no matter how much access you grant on top, and the client rewrites that deny entry on every sync run, so it comes right back.
It is tracked here, and both are still open:
I would add your setup and a short log snippet to the first one and give it a thumbs up, the more confirmations it gathers the more likely it gets picked up. Your 33.0.7 is worth mentioning there, it shows the bug is still live in the current client.
The honest part is that there is no clean fix on Windows yet. The chmod 755 workaround people bring up in the issue is a Linux thing and does not carry over, because the client just reapplies the deny entry regardless. Until it is fixed, the reliable way to reach that read-only content is to take the folder out of the sync client and get to it over WebDAV instead, where none of this ACL enforcement is in play. For exactly that kind of case I would point you at a small tray client I maintain, NcDavTray, which mounts your Nextcloud over WebDAV and gives you straight access to read-only shares like this one:
The other option, if you really need it mirrored into the local filesystem and that is acceptable, is to ask whoever shared it to grant you write permission, since read-write folders sync without any of this, as you already saw with your first gigabyte.
A big thank you for your very informative reply.
This saves me a lot of time that I would otherwise have spent on further fruitless troubleshooting on my end.
I use NextCloud in combination with Cryptomator for my personal file storage.
My use case is that I want to give a few loved ones read-only access to my file storage.
Where I set up my loved ones’ PCs myself, I can now consider whether I want to take the risk of relying solely on Cryptomator’s ‘Read-Only’ option, without the protection provided by the ‘Read-Only’ setting in NextCloud.