nextcloud
[Bug]: GroupFolders permission changes not reflected in Windows Desktop Client VFS
⚠️ Before submitting, please verify the following: ⚠️
- [x] This is a bug, not a question or a configuration issue.
- [x] This issue is not already reported on Github (I've searched it).
- [x] Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
- [x] I agree to follow Nextcloud's Code of Conduct
Bug description
When Advanced Permissions (ACLs) on Group Folders are changed server-side (for example: a file or folder permission is changed from read-only → read+write), the Nextcloud Windows Desktop client with Virtual File Support (VFS) does not update its in-memory permission state. The client continues to treat affected placeholders as non-writable and blocks operations (delete/rename/write) with "access denied" errors, while the server (web UI / WebDAV) already allows the operation.
A manual workaround is to toggle Virtual File Support (Disable → Enable) in the desktop client or to restart the desktop client — that forces a full rehydrate and clears the in-memory cache so the new permissions take effect. This manual workaround is not feasible at scale.
Steps to reproduce
- Enable Group Folders with Advanced Permissions and set a user’s access to Read-Only.
- On Windows, sync the folder using Nextcloud Desktop Client (VFS enabled), then change that user’s permission on the server to Read & Write.
- Try to delete the same file in Windows → the client still shows Access Denied until VFS is manually disabled and re-enabled.
Expected behavior
After changing a user’s permission from Read-Only to Read & Write in Group Folders, the Windows Desktop Client (with VFS enabled) should automatically refresh the updated permissions and allow file deletion without requiring a VFS disable/enable cycle.
Which files are affected by this bug
Affected Files / Scope All files and folders inside Group Folders that have Advanced Permissions (ACLs) set. Specifically, files where a user’s permission changes after the placeholder has already been created on the Windows client with VFS enabled. Any placeholder files that the client has already cached before the permission change are affected. Files accessed directly via Web UI or WebDAV are not affected; the issue only impacts the Windows Desktop Client with VFS. In short: all previously synced placeholders in Group Folders with ACL changes can exhibit this bug.
Operating system
Windows
Which version of the operating system you are running.
Windows 11
Package
Official Windows MSI
Nextcloud Server version
32.0.2
Nextcloud Desktop Client version
32.0.2.2
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 3.16.1 to 3.16.2)
Are you using the Nextcloud Server Encryption module?
Encryption is Enabled
Are you using an external user-backend?
- [ ] Default internal user-backend
- [x] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
Nextcloud Server logs
Additional info
No response
I haven’t encountered the issue exactly as described, but I did notice that after updating the permissions on an account, the change wasn’t reflected until I triggered a manual sync. Instead of re-syncing the entire connection, click Sync now on the current sync, then navigate to the parent folder and into the affected subfolder where the rules were modified. Make a small change there and the updated permissions should apply. This worked consistently on my side.
I haven’t encountered the issue exactly as described, but I did notice that after updating the permissions on an account, the change wasn’t reflected until I triggered a manual sync. Instead of re-syncing the entire connection, click Sync now on the current sync, then navigate to the parent folder and into the affected subfolder where the rules were modified. Make a small change there and the updated permissions should apply. This worked consistently on my side.
Yes, that’s correct — this issue is resolved using the method you mentioned. However, I believe this part of the sync process should also happen automatically, because regular users may find it difficult to understand or notice this.
which release are you using ? @parsmmm if you expect quick update from the server to the client, you need to have the files notify push app installed so if pressing the sync button is enough to fix the issue then it is not an issue closing
which release are you using ? @parsmmm if you expect quick update from the server to the client, you need to have the files notify push app installed so if pressing the sync button is enough to fix the issue then it is not an issue closing
We have push Notify setup and we are currently working through this issue.
We had all their files on read only until we cutover from Synology Drive and then after enabling write for all ACL's on the team folders we found that upwards of 22,000 out of roughly 500,000 - 1,000,00 (depending on the user) files for some users were still read only.
Enabling and disabling Virtual Files makes the client perform a check and counts up the files still in read only and fixes them but this is very manual procedure.
which release are you using ? @parsmmm if you expect quick update from the server to the client, you need to have the files notify push app installed so if pressing the sync button is enough to fix the issue then it is not an issue closing
We're using 32.0.1, with v4.0.3 on Clients.
Testing Daily builds too on a few test machines (looking forward to lazy loading)