Nested groupfolder sync broken with Nextcloud desktop client

[Abraxas0]

Steps to reproduce

1. Create a group folder (e.g. "Parent Directory")
2. Create a sub group folder (e.g. "Parent Directory/Sub Directory")
3. Create a plain text file at parent directory (-> will be synced to server and all Windows clients)
4. Create a plain text file at sub directory (-> will be synced to server and all Windows clients)
5. Change the plain text file at parent directory (-> will be synced to server and all Windows clients)
6. Change the plain text file at sub directory (-> will be synced to server, but not to any Windows client)
7. Change the plain text file at parent directory again or make any change to the parent directory (-> will be synced to server and all pending changes from step 6 will now be synced to all Windows clients too)

This behaviour affects only nested group folders, not plain sub directories in a group folder.

Expected behaviour

All changes of files pushed to or made on the server (create, modify, delete of a file) inside nested group folders should be pushed to all clients.

Actual behaviour

Changes of files pushed to or made on the server (create, modify, delete of a file) inside nested group folders are pushed to Windows clients only if any change have been made to at least one file inside the root group folder.

Server configuration

Operating system: CentOS Linux release 7.9.2009

Web server: Apache/2.4.35

Database: 10.4.21-MariaDB MariaDB Server

PHP version: PHP 7.4.25

Nextcloud version: 22.2.3

Group folders version: 10.0.0

Updated from an older Nextcloud or fresh install: Update

Where did you install Nextcloud from: tar.gz from official source

Are you using external storage, if yes which one: no (local)

Are you using encryption: no

Are you using an external user-backend, if yes which one: ActiveDirectory

Client configuration

Browser: Firefox 94.0.2, Nextcloud Desktop-Client 3.3.6

Operating system: Windows 10 Pro, 10.0.19043

Logs

Web server error log

I'm sorry, but no errors have been logged to Apache vhost log during test.

Nextcloud log (data/nextcloud.log)

I'm sorry, but no events have been logged to nextcloud.log during test.
Nextcloud loglevel is 3.

[michaelberg79]

Same Problem at my device
No poll for subfolders within the groupfolders.
No error within desktop client logs and server-logs.

Server Version: 22.2.3
Desktop Client Version: 3.3.6
Windows 10
No Firewall between desktop client and nextcloud server.

The behavior exists for a long time and many versions. Only ignored it and got the changed new and chaned files by disabling and enabling the sync for the folder.

[Abraxas0]

Additional info:

I've made some tests with a 3rd level of group folder right now. It seems that changes to files in the 1st and 3rd level trigger sync, but not on 2nd level.

[fschrempf]

Related or duplicate: #652 and nextcloud/desktop#1773

[atdqm]

I see the same issue on my configuration

Server Version: 25.0.2
Groupfolder : 13.1.1
Desktop Client Version: 3.5.4 (Linux Ubuntu 20.04) and 3.7.3 (Windows 10)

---

I understand that we can use groupfolders with the sync client only if we don't use subfolders.
We can create subfolders but not in the GroupFolders application, only by users in the shared folder

[B5JohnSheridan]

We also stumbled about this problem and it took us quite a while to narrow it down to be a groupfolder issue and then finally to find this issue. In our case, syncing was working in some folders and for some people without problems, while for others it did never work without hard tricks like clearing sync.db or resetting the ignore file list.

We now implemented a crude solution: Using watchman we are watching for all nested groupfolders /mnt/ncdata/__groupfolders/<foldernr> and the trigger script is then updating a file in the parent groupfolder of that groupfolder (e.g. for groupfolder A/B, we update a file in A), which, as described in "7." above then triggers a sync that also updates all nested folders accordingly.

Likely not something you want to do in large installations, but for the time being it saves us from completely rebuilding our structure to a flat layout etc.

Would be really nice if a fix finally could be implemented for that. What is the show stopper here? Is there something we can contribute? If not code, maybe something else? ;-)

[VVD]

It isn't just Windows related - on other platforms it doesn't work too.
I'm using FreeBSD on both desktop and server and have this issue.
My scenario for reproduce:

1. Create groupfolder /Test1, then /Test1/Test2 and configure access.
2. Turn on in Nextcloud Desktop Client sync of the /Test1 and /Test1/Test2.
3. In Nextclod web interface create file /Test1/Test2/test.txt.
4. Check local storage connected via Nextcloud Desktop Client - no new file /Test1/Test2/test.txt.
5. In Nextclod web interface create file /Test1/test.txt.
6. Check local storage connected via Nextcloud Desktop Client - both files are here /Test1/Test2/test.txt and /Test1/test.txt.

My environment:

Server configuration

Operating system: FreeBSD 13.2-p9 amd64
Web server: Apache 2.4.58
Database: PostgreSQL 15.5
PHP version: PHP 8.2.14
Nextcloud version: 27.1.5
Group folders version: 15.3.2
Updated from an older Nextcloud or fresh install: Update via web-based internal updater
Where did you install Nextcloud from: tar.gz from official source
Are you using external storage, if yes which one: no (local)
Are you using encryption: no
Are you using an external user-backend, if yes which one: IMAP4 via External user authentication 3.2.0

Client configuration

Browser: Firefox 121.0, Nextcloud Desktop-Client 3.10.1, 3.11.0
Operating system: FreeBSD 13.2-p9 amd64

@Abraxas0, please rename issue - replace Windows client with something like Nextcloud desktop client. I couldn't find this issue for a long time because of the title.

P.S. 4 years have already passed, but the bug is still here...

[stullekovski]

Hi all,

if I got you right I've got the strange behavior with some of my group folders too.

The Windows Desktop Client is not downloading the content of a group folder but uploading new files (as I can see right away on the web gui).
Tried group folders with only 1 subfolder and permission group with users for it.

The client shows every folder (downwards too) in the client settings (so permissions are working).
If I check the box, the folder will download the latest content, but only once! So I’ve to uncheck and check the box 3 times a day or so. That’s not helpful.
Even if I hit “sync now” or “force sync” there’s no change aka download.
Only if I edit permissions as admin for the folder/group or hit the boxes it works once.

Do you have any idea?
Thanks a lot!

NC Client: 3.11 Windows 10/11
NC Server: 27.1.5.1

[B5JohnSheridan]

Hi stullekovski,

if your problem appears only in nested group folders (e.g. Folders with a "/" in the name), then it clearly sounds like you are affected from the same issue. As your wrote, if you change something, it gets uploaded right away, but incoming changes are not synced unless you do what you did. But for us, it helped (actually 100% solved the issue), if the top level group folder has an update. So if your problem is in group folder "upper/lower", then try changing something in group folder "upper" and I guess then outstanding changes in "upper/lower" will be synced with it.

As written above, we use watchman to find changed in the file system for nested group folders and then modify the corresponding top level group folder to force the sync to happen.

If you are interested in this crude fix (until hopefully a final fix is released) feel free to ask.

[VVD]

I added to system cron on my workstation (crontab -e):

*       *       *       *       *       /usr/bin/touch /path/to/1st-level/groupfolder1/test.txt

This workaround work for subfolders of groupfolder1. If you need sync other groupfolder2 too, then you must add /path/to/1st-level/groupfolder2/test.txt to end of line in crontab.

[B5JohnSheridan]

Yes, but that triggers a sync in groupfolder1 and all nested subfolders groupfolder1/a groupfolder1/b etc. every minute, even if there is no change otherwise. Therefore the idea with watchman, so that the touch only occurs if something was changed in one fo the affected folders.

Additionally, we had issues when touching files directly in the ncdata folder on the file system. This was not always working. So we actually mounted a the cloud directory via davfs and touched the file there. This works reliably.

[stullekovski]

Alright, I see. And thanks for your workarounds.
For now it looks like this works too:

I think this should work, if you grant maximum permissions (e.g. write) in the "normal" group folder permissions. Then restrict the permissions to "read" using ACL on the root folder. Then grant write permissions for the subfolder and group you like.

#655 (comment)

Will see. Even it's a weird way. ;)

[B5JohnSheridan]

Ooookay, that would be interesting. From my understanding of the issue, I would be quite amazed, if that really works. Let us know! We are still talking separate groupfolders group1, group1/a and group1/b and not just groupfolder group1 with normal subfolder a and b in it? Because the latter works of course, as non-nested groupfolders sync without an issue. But the latter is also a hassle if you have very specific permissions, as you need to grant all permissions on group1 and then revoke them again etc., as you wrote. For our setup to complicated and risk of error too high...

[artonge]

The issue might be fixed with the following PR: nextcloud/server#44279
Could one of you apply the PR and confirm that the issue is solved?

[B5JohnSheridan]

Testing will take a while for us, as we cannot test this on our productive system and it requires some initial setup to test.

However, I am very sure we had this issue also on subfolders that were created after the top folder. So it might be, that we created first g1/g2 and then g1 but afterwards we created g1/g3 and that folder showed the same buggy non-syncing behaviour. So if the now fixed bug really only triggers due to creation order, I doubt it will fix the issue completely?

[VVD]

The issue might be fixed with the following PR: nextcloud/server#44279 Could one of you apply the PR and confirm that the issue is solved?

Patch work for me on 27!

[artonge]

Closing, feel free to reopen if we missed a use case.