[Bug]: Group Folder shares within folder lost when original owner is gone from group

[jaschrock]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

A group folder that was shared with a user (user a) from the group had a subfolder underneath it. That was shared via nextcloud to another user (user b). When that original user no longer was a part of the group (user a) that left (user b)'s share in a strange state. It was still there, kind of, but didn't work. And, trying to add in the user via another group user (user c) also was not right. It would look like the user was being added in, but when you look later at the folder the person wasn't there. After adding in user a again to the group I could see that user's share (user b), unshare it, then go back to user c and it allowed the folder share to stick with the new user.

Steps to reproduce

1. Create group folder and share with a group that has user A in it (and user C)
2. create a subfolder
3. Login as user A
4. share subfolder with user B
5. put a file in to new subfolder for good measuer.
6. take user A out of the group
7. Login as user C
8. You will see the share no longer has user B as a part of it. If you try to add in user B, it looks like the person is added, but they really are not (since it is confused because they aren't visible - they actually are still shared).
9. Add user A back into the group
10. go to the shared subfolder and unshare it with user B
11. now login as user C and share the subfolder with user B again. This time it will "stick" and show the user properly. Also the user will be able to see the folder again.

Maybe this is a "feature", but if so it is somewhat improperly implemented as that hidden share should be at least able to be deleted or delegated or something and not have this current behaviour. But with the group folder, I would think the share should stick. That is why group folders are there to make them not dependent on the specific users coming and going. Seems the shares should be owned by the group not the user.

Expected behavior

When the user leaves the group, the share that was made should remain (or at minimum still be able to be managed by other users of the group).

Nextcloud Server version

30

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Apache (supported)

Database engine version

MariaDB

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

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "webshare.eunc.edu"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0
        },
        "dbtype": "mysql",
        "version": "30.0.5.1",
        "overwrite.cli.url": "https:\/\/webshare.eunc.edu",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "ldapIgnoreNamingRules": false,
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
        "updater.release.channel": "stable",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "PLAIN",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "mail_smtpstreamoptions": {
            "ssl": {
                "allow_self_signed": true,
                "verify_peer": false,
                "verify_peer_name": false
            }
        },
        "maintenance": false,
        "maintenance_window_start": 3,
        "versions_retention_obligation": "7,365",
        "theme": "",
        "lost_password_link": "https:\/\/password.eunc.edu",
        "loglevel": 0,
        "log_type": "file",
        "logfile": "\/var\/log\/nextcloud\/nextcloud.log",
        "logfilemode": 416,
        "logdateformat": "F d, Y H:i:s",
        "log_rotate_size": 104857600,
        "default_phone_region": "DE",
        "knowledgebaseenabled": false,
        "allow_user_to_change_display_name": false,
        "session_relaxed_expiry": false,
        "trashbin_retention_obligation": "auto,30",
        "defaultapp": "files",
        "login_form_autocomplete": true,
        "login_form_timeout": 300,
        "session_lifetime": 28800,
        "login.alternatives": [
            {
                "href": "\/index.php\/apps\/user_cas\/login",
                "name": "CAS Login",
                "img": "\/apps\/user_cas\/img\/cas-logo.png"
            }
        ],
        "twofactor_enforced": "false",
        "twofactor_enforced_groups": [],
        "twofactor_enforced_excluded_groups": [],
        "app_install_overwrite": [
            "groupfolders",
            "fulltextsearch_elasticsearch"
        ]
    }
}

List of activated Apps

Enabled:
  - activity: 3.0.0
  - app_api: 4.0.5
  - bruteforcesettings: 3.0.0
  - cloud_federation_api: 1.13.0
  - comments: 1.20.1
  - contactsinteraction: 1.11.0
  - dav: 1.31.1
  - federatedfilesharing: 1.20.0
  - files: 2.2.0
  - files_downloadlimit: 3.0.0
  - files_fulltextsearch: 30.0.0
  - files_pdfviewer: 3.0.0
  - files_reminders: 1.3.0
  - files_sharing: 1.22.0
  - files_trashbin: 1.20.1
  - files_versions: 1.23.0
  - forms: 4.3.6
  - fulltextsearch: 30.0.0
  - fulltextsearch_elasticsearch: 30.0.0
  - groupfolders: 18.0.9
  - logreader: 3.0.0
  - lookup_server_connector: 1.18.0
  - notifications: 3.0.0
  - oauth2: 1.18.1
  - password_policy: 2.0.0
  - photos: 3.0.2
  - polls: 7.2.9
  - privacy: 2.0.0
  - provisioning_api: 1.20.0
  - related_resources: 1.5.0
  - richdocuments: 8.5.3
  - serverinfo: 2.0.0
  - settings: 1.13.0
  - sharebymail: 1.20.0
  - support: 2.0.0
  - systemtags: 1.20.0
  - theming: 2.5.0
  - twofactor_backupcodes: 1.19.0
  - updatenotification: 1.20.0
  - user_ldap: 1.21.0
  - user_status: 1.10.0
  - user_usage_report: 1.14.0
  - viewer: 3.0.0
  - weather_status: 1.10.0
  - webhook_listeners: 1.1.0-dev
  - workflowengine: 2.12.0
Disabled:
  - admin_audit: 1.20.0
  - circles: 30.0.0 (installed 25.0.0)
  - dashboard: 7.10.0 (installed 7.0.0)
  - encryption: 2.18.0
  - extract: 1.3.6 (installed 1.3.6)
  - federation: 1.20.0 (installed 1.19.0)
  - files_external: 1.22.0 (installed 1.6.0)
  - files_rightclick: 0.15.1 (installed 1.6.0)
  - firstrunwizard: 3.0.0 (installed 2.18.0)
  - nextcloud_announcements: 2.0.0 (installed 1.18.0)
  - recommendations: 3.0.0 (installed 2.1.0)
  - survey_client: 2.0.0 (installed 1.17.0)
  - suspicious_login: 8.0.0
  - text: 4.1.0 (installed 3.1.0)
  - twofactor_nextcloud_notification: 4.0.0
  - twofactor_totp: 12.0.0-dev

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Additional info

No response

[solracsf]

Moving to Group Folder repo as it seemps specific to that app.
Also reformetd the Reproducing steps for better lisibility. 👍

[provokateurin]

Unfortunately we can not solve this problem.
I considered working around this limitation when I worked on nextcloud/server#49073, but we realized that it is better for shares to disappear in order to prevent any unwanted data leaks.
For example when a user is removed from a group or deleted completely (maybe they did something malicious or just left the organization), they should not be able to still have access to the data through shares they have created before (e.g. public link share).

[jaschrock]

The problem, however, is the way it is now, if you try to add in that share again at the same folder it fails. It looks like it is adding it, but it doesn't. And, since it doesn't show, you can't do anything but go back in as that user and delete it. So, if it can at least be seen and deleted as a non functional share, it can be fixed. Right now, it is permanently broken for that user. that is the scenario I believe still needs fixed.

I understand, though, the philosophy behind it.

[jaschrock]

I would also note that the whole idea behind a group folder is that you have a consistency for when people are out of a group the data persists. This kind of violates this rule. In this case, I dropped from the group (as it was no longer my responsibility) but another committee member that was given access at a lower level is still in the group and lost acceess (and until I added myself back into the group, deleted his share) I couldn't actually add him back into the group. He just also magically stopped having access without any explanation. This also isn't the behaviour with the normal shares as I tested that. I do understand the problem, but I think the current solution is flawed.