Group Folders Advanced Permissions not working


I don’t know if it’s a bug or a configuration error .

I want to to the following

Create a user = user1 and a group = group1 with user1 in it.
Create a groupfolder = folder1
-> with groups = group1 and no permissions
-> with advanced permissions = user1

User1 gets all permissions in the advanced permission rule (read, write, create…)
-> so members in group group1 should be read-only
-> User1 should be able to create folders, files and delete them (full-access)

But in this example user1 is read-only, seems like the advanced permissions are ignored.

Anybody have any idea?

Nextcloud 18.0.0
GroupFolders 6.0.1

Hi there,

I’ve got the exact same problem on two different instances (18.0 and 17.0.3) for several months now.
A couple of issues are opened on github :

The best workaround for now seems to be this one :

But let’s hope for a real fix.

Okay thanks, looking forward to a fix.

My feeling is actually the current model is correct. The overall control on a group folder is intentionally that it is controlled by central admin -so for example if central admin (the management) want to have a folder with material for the company to have access to but not share, then that is controlled at the group folder creation level, a facility which is restricted to a small number of people. So at group folder level grant to groups the maximum permissions you would want any given group to have and restrict backwards from there with the advanced permissions.

At which point there’s still a bug, it’s just in the advanced permissions UI implying you can grant permissions that you cannot.

I had the exact same issue, and I found a solution.

As @putt1ck said, it works as designed.
In the documentation it states the following:

Denied permissions configured for the group folder itself cannot be overwritten to “allow” permissions by the advanced permission rules.

Therefore, the permissions in the group folder need to be set to “allow” if you want groups to be able to use them down the folder tree line.

To accomplish what you seek, you need to set the advanced permission rules on the group folder itself, and deny all but read permissions for all groups. This way you accomplish the same as denying permissions in the group folder settings panel. Groups can now be allowed to write/delete/share with advanced permission rules down the folder tree line in their respective sub folders.


Thanks. This helped me to understand how permissions on group folders works.

This may be the way that permissions are intended to work, but it is still not ideal.

I may be wrong, but it seems to me that this is very inconvenient when needing to preserve a folder structure.
I cannot preserve a folder structure and allow users to delete files within the folder. To preserve the folder, I must deny deletion permissions on it, which in turn denies deletion of files within the folder.

Hi all,

Just read the thread as I had the same issue (opened my own thread at Group Folders don't accept read conditions). I understand that permissions should be set first, then denied for groups/users who should be restricted.

However, as @bushrang3r says, this looks wrong to me too! Actually, most of people engaged in nextCloud setup and maintenance have some knowledge on file permissions and it looks common sense when you want to have 1 single people allowed to manipulate the file structure to deny all rights by default, enabling the only ‘admin’ with the proper rights, and not the other way!

In my case, I want to have a SHARED folder where we could build one folder for each partner/customer: any customer should have:

  • Read-only rights on the SHARED folder (to be able to find it ;-)),
  • NO rights on the SHARED subfolders to protect from indiscretion,
  • ALL rights on his subfolder
    I still haven’t find any way to set this up with Group Folders, as I don’t want to list all users and deny rights for each of them on all subfolders! By the way it could be simply set on the underlying Debian…

Thanks in advance for any help!


Exactly, should be the way @jlgarnier describes.

Would make it easier for a lot of people, dealing with the same problems understanding the way permissions in groupfolders are working.


@thomasga This issue is solved since the latest update of groupfolder !!