[Bug]: 3.15.0 does not handle local write restriction correctly for read-only (group) folders

[nursoda]

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github, other reports differ.
• Nextcloud Server and Desktop Client are up to date.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

My local sync client has permission issues with a group folder to which the user is only granted read-only access.

On Linux, macOS and Windows, I get an error when removing a subfolder from a read-only folder in sync settings.

If another user with write access deletes a file or folder within such a synced read-only folder, windows correctly deletes that file, macOS yields an "unknown error: 513" (and re-syncs as usual but then yields the error again) while the sync client constantly syncs on Linux (see screencast below).

Steps to reproduce

My local user L account syncs a to a Nextcloud 28.0.12 using Desktop 3.15.0. One of the synced folders is a group folder F. The Nextcloud user U has restricted access (read-only) to that folder F. F contains a sub-folder S.

Issue 1: (De)Selecting folders in Nextcloud Desktop settings (Linux, Windows, macOS)

If I deselect S in the Nextcloud Desktop settings and apply, a sync is triggered. That (and subsequent) syncs yield an error: "S: access denied":

I can fix that by manually re-adding write access for L to F and S (chmod u+w F F/S). Then, the sync client deletes the folder and it's read-only (444) file! and resets the access mode of F to 555.

If I now re-select S in the Nextcloud Desktop settings and apply, a sync is triggered and S is added correctly (with 555). If I had manually added write access to F beforehand, it also is reset to 555 for F upon adding a subfolder.

Issue 2: External deletion of a file/folder within a read-only folder (Linux and macOS)

If some other Nextcloud user V (with regular write access) changes any file within F, these changes are written correctly to the local file, although that file is read-only. However, when V deletes a file or folder within F, my sync client enters an endless re-sync loop on Linux:

syncloop.webm

On macOS the deletion triggers an "Unknown error: 513" and runs into that again on each sync.
On Windows, the remote deletion works as expected: the local (read-only) file is deleted correctly.

The only way I found to remedy this situation was to manually recursively give write access to all folders from S to the deleted file/folder. Then, the sync client deletes that file/folder and removes write access again.

Expected behavior

It seems to be reasonable to deny write access to files on a system level, but the sync client should be able to override them. It does that for synced files but the devs (and tests!) seem to have missed folders and the deletion scenario. The user must be able to deselect subfolders and sync incoming deletions without errors.

Which files are affected by this bug

test.md

Operating system

Linux

Which version of the operating system you are running.

EndeavourOS = Arch Linux, up-to-date

Package

Distro package manager

Nextcloud Server version

28.0.12

Nextcloud Desktop Client version

3.15.0

Is this bug present after an update or on a fresh install?

Updated to a major version (ex. 3.3.6 to 3.4.0)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• Default internal user-backend

Additional info

I cannot attach the Linux Debug Logs since this is my regular business PC and the files within the Debug ZIP cannot easily reduced to one cloud instance. Thus the files would yield information on clouds of my customers.

But I captured just the cloud I tested with on Windows and macOS now:

3.15.0-W11.zip
3.15.0-mac.zip

[ctr49]

I'm running into the same issue with 3.14.4 on Linux, also using group folders. files are created 444, directories 555. Now when remote changes something - or when using VFS in suffix mode the file needs to be recreated file.nextcloud to file the lack of write access to the folder seems to create all sorts of sync trouble.

[nursoda]

@mgallien Thanks for 3.15.2 – yet this issue seems to have slipped everyone's attention. It is NOT Linux-only, but affects anyone using read-only folders – not sure whether only group folders. But the many small NGOs I support (more their users) struggle since the bug was introduced. Please have a look whether you may reproduce.