ACL not working with group folders

[ClCfe]

Hello

I am using Nextcloud 16.0.4 and groupfolder 4.1.0
I am not sure if this is a nextcloud or groupfolder bug

How to reproduce:

In admin panel
Create a group folder
Assign a group to this group folder, with no write/share/delete permissions
Enable ACL on this folder

Then go to Files panel
browse to a subfolder of this group folder
add an ACL on the subfolder for a member of the group previously assigned
first bug: inherited rights says that user can read/write/create/delete/share
give all perms : read/write/create/delete/share

The user can't upload or delete anything
He also has a message saying "You don’t have permission to upload or create files here"

[andreasdeschka]

I have the same issue.

A workaround is to give in the group folder to a group write/share/delete permissions.

Then go to the folder and create an ACL and deny the permissions you want.

It seems that denying a permission at the creation of the group folder and later giving it back with ACL settings ist not working.

[kesselb]

Seems to be groupfolders related. Still an issue?

[kort3x]

Same problem here.

My issue: #745

[kort3x]

#749 seems to be related

[putt1ck]

Been thinking this through and the bug is not that the permissions cannot override that set for the group folder, because the point of the group folder is that there is central control; the bug is in the UI for advanced permissions, which should not allow people to think they can override them.

[tazinblack]

I have the same issue.

A workaround is to give in the group folder to a group write/share/delete permissions.

Then go to the folder and create an ACL and deny the permissions you want.

It seems that denying a permission at the creation of the group folder and later giving it back with ACL settings ist not working.

Same issue here.

Maybe it's not my brightest moment but your workaround does not work for me in 19.0.0 with groupfolders 6.0.6.
I try to set it up with occ command from cli. Everything I try overwriteing the global permissions of the group folder in a subfolder is not working

[CoMPaTech]

I've read through the linked issues (#745 #749 and #598) at one deployment we run into both permission denied for maps as for files, but much more intermittently. The problem isn't reproduceable within the UI as indicated in these issues. From the UI we can create maps or upload files, it's the client that's giving us problems.

Do note that intermittency is key here, while I do show you the errors below, the user without problems created other submaps, deleted them and the same with files. At the higher, same or even lower layer. So it looks 'sort of random', but once a folder or a file is 'permission denied' it stays that way. Debugging client files (as shown below), server files (nothing really showing) or even tcpdumping doesn't yield clues.

The (redacted) debug-log on the client looks like (where X1 and X2 are different folders): (errors are in Dutch (nl/nl))

[OCC::PropagateItemJob::scheduleSelfOrChild 	Starting INSTRUCTION_ERROR propagation of "A/B/C/D/X1/Y/Z/some.pdf" by OCC::PropagateIgnoreJob(0x600002ae38c0)
[OCC::PropagateItemJob::done 	Could not complete propagation of "A/B/C/D/X1/Y/Z/some.pdf" by OCC::PropagateIgnoreJob(0x600002ae38c0) with status 2 and error: "Niet toegestaan omdat u geen rechten hebt om bestanden in die map toe te voegen"
(...)
[OCC::PropagateItemJob::scheduleSelfOrChild 	Starting INSTRUCTION_ERROR propagation of "A/B/C/D/X2/Y" by OCC::PropagateIgnoreJob(0x600002aeb3c0)
[OCC::PropagateItemJob::done 	Could not complete propagation of "A/B/C/D/X2/Y" by OCC::PropagateIgnoreJob(0x600002aeb3c0) with status 2 and error: "Niet toegestaan, omdat je geen permissies hebt om submappen aan die map toe te voegen"
(...)
[OCC::SyncEngine::checkForPermission 	checkForPermission: ERROR "A/B/C/D/X2/Y"

To be clear on the permissions level, on "/A" and "/A/B" there is only view-rights - on "/A/B/C" the group has all available rights. Sharing is not enabled at all on this instance. Just view this as /A is devision and /A/B is a department. People get their access rights on maps within the department, there is really no additional permissions. Allowing on "/A" or even "/A/B" and then negating won't be working in this setup if I read the experiences right.

Any clues or additional things I could look into? Bumping server to debug didn't get us much more information and it does work from the UI. (i.e. I can either impersonate the user or add myself to the group and make it work).

[markus61]

Been thinking this through and the bug is not that the permissions cannot override that set for the group folder, because the point of the group folder is that there is central control; the bug is in the UI for advanced permissions, which should not allow people to think they can override them.

ui does not properly reflect inherited permissions too. one should expect that whatever an admin selects should be inherited by ui. the ui seems to display permissions for everything instead. at least on the group folder iteself.

[CoMPaTech]

We've so far concluded that remotePerms in the sqlite DB on the client is empty -> hence causing the issues, but no real solution yet. So I guess they are different issues (if we - by various non-consistent actions - get the client to talk to the server (in more than a few bytes), it does regenerate and plays along for a few days).

[Pytal]

Closing in favour of #655