-
Notifications
You must be signed in to change notification settings - Fork 917
Description
β οΈ Before submitting, please verify the following: β οΈ
- This is a bug, not a question or a configuration issue.
- This issue is not already reported on Github (I've searched it).
- Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
- I agree to follow Nextcloud's Code of Conduct
Bug description
Bug description
After migrating from the classic sync client to the new VFS/File Provider client on macOS, it seems that existing E2EE folders become completely inaccessible, with no apparent way to recover them from the desktop client.
Additional context
It is worth noting that even with the previous classic sync client, the E2EE folder had a recurring tendency to unmount itself, requiring the user to manually remount it each time from within the Nextcloud client settings. This seemed to be an already known instability with E2EE folder mounting on macOS or a deliberate choice.
As a consequence, when the account was disconnected to switch to VFS/File Provider mode, the E2EE folder happened to be in its unmounted state β which may have contributed to it not being properly taken into account during the transition, and could explain why it is now completely inaccessible.
This suggests that the E2EE + macOS combination may have had underlying issues predating the VFS migration, and that the migration process does not seem to handle the case where an E2EE folder was not mounted at the time of disconnection.
Steps to reproduce
Have an existing Nextcloud account on macOS with one or more E2EE folders synced via the classic client
Disconnect the account and reconnect using the new VFS/File Provider mode (requires the dedicated VFS client)
Observe that E2EE folders do not appear in ~/Library/CloudStorage/
Attempt to add the E2EE folder as a classic sync folder via Preferences β Add folder connection β the folder path field accepts input but never validates/confirms the addition
Attempt to pin the E2EE folder as "Always keep on this device" β not possible since the folder is not visible in Finder
Expected behavior
E2EE folders should either appear in the VFS File Provider view (possibly as always-offline items), or there should be a way to add them as a separate classic sync connection alongside the VFS account.
Actual behavior
E2EE folders are not visible in ~/Library/CloudStorage/ under the File Provider
Adding a classic sync folder in parallel seems to be blocked, possibly due to Apple's FileProvider restrictions that prevent classic sync and File Provider from running simultaneously
The folder path input in the "Add folder connection" dialog accepts the E2EE folder name but does not proceed to confirmation, regardless of the path format used (/FolderName, FolderName, with or without escaped spaces)
Workaround attempts
Tried accessing and downloading files via the NC33 web E2EE browser feature (requires enabling E2EE in personal settings): the interface shows the files but the download of decrypted files does not seem to complete successfully
Mobile client was not tested in this specific scenario
Impact
Files stored in E2EE folders prior to the VFS migration appear to be unrecoverable from the desktop client on macOS. This seems like a significant regression for users who had working E2EE folders before migrating to the new VFS client.
Environment
Nextcloud Server: 33.0.x (Hub 26 Winter) β AIO deployment (upgraded from Nextcloud 32)
Desktop Client: latest VFS client for macOS : Nextcloud 4.0.6 VFS
macOS version: macOS 26.3
Reverse proxy: BunkerWeb 1.6.8
Steps to reproduce
- Right click on the file
- Click on Share Options
- The share dialog does not display the option to share by e-mail
...
Expected behavior
When clicking on the share dialog, share by e-mail should be an option.
...
Which files are affected by this bug
E2EE Folder and files
Operating system
Windows
Which version of the operating system you are running.
macOS 26.3
Package
Official macOS Virtual files 12+ universal pkg
Nextcloud Server version
33.0.0
Nextcloud Desktop Client version
4.0.6 VFS
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
- LDAP/ Active Directory
- SSO - SAML
- Other
Nextcloud Server logs
Additional info
No response