Share still exists after source file gets deleted in group folder

[chaosgrid]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Steps to reproduce

Note: Deleted files (trashbin) app needs to be activated.

1. Create a group folder and create a subfolder or file in that group folder.
2. Share this subfolder or file to a another user.
3. Delete the file/subfolder

Expected behaviour

The share should get deleted with the file deletion.

Actual behaviour

The share does not get deleted, the other user can still see the share but clicking on it will not work (file not found). If the source file gets permanently deleted from the trashbin, the share will no longer display for the other user and the oc_share table will get cleaned up by the next run of the cron job.

Nextcloud version: 22.2.0

[CarlSchwan]

Confirmed with master

[kdoteu]

Still reproducable in 25.0.1. Like ticket said, deleting the files from trash also removes the shares. But this is not like the normal (not groupfolder) sharing works in my experience.

Got a lot confusion for my users :/

[Nils98Ar]

We have the same problem in NC 26...

[chaosgrid]

According to https://github.com/nextcloud/server/issues/46369 this might be intended behaviour since when restoring a file you might want to also auto-restore the shares. But it is still a bug, since for a shared file in the trashbin, this file should no longer display for the other users that are receivers of the share.

Is this issue maybe better located in https://github.com/nextcloud/server instead of here in the groupfolders app?

[Nils98Ar]

Does the problem also exist for shared files/folders outside of groupfolders?

[narcisgarcia]

I see still in NC 31, orphan shares aren't cleaned by cron task. In my case it is a reshared External storage.

[narcisgarcia]

In a NC 31 instance, I had orphaned shares because of origin resource was removed (external storage->reshared). After several days, cron job did not clean this. Today I've run "occ sharing:delete-orphan-shares" and it seemed to clean those orphan shares; target users do not see them anymore.

BUT: Target users have old name "reserved" and it's prevented to receive a share with same old name. Example:

1. An external storage is mounted from admin with local name "OtherDocs" and authorized to a Main user
2. Main user reshares "OtherDocs" to Secondary user. Secondary user sees this as "OtherDocs"; right.
3. External storage is unmounted.
4. External storage is mounted again with same setup (name "OtherDocs", full-authorization to Main user)
5. Main user reshares "OtherDocs" to Secondary user. Secondary user still sees dol/bad "OtherDocs" and now also sees "OtherDocs (2)"; I understand orphan "OtherDocs" is still not removed by cron task in NC 31.
6. Server administrator runs "sudo -u www-data php occ sharing:delete-orphan-shares" and confirms cleanup.
7. Secondary user now does not see "OtherDocs" and sees only "OtherDocs (2)". Tries to rename "OtherDocs (2)" to "OtherDocs". It seems to perform rename right.
8. Next session Secondary user sees received share as "OtherDocs (2)". No solution, unless Seconday user renames it to ANY OTHER NAME BUT "OtherDocs".