[Bug]: Deleting file or folder leaves orphaned share links

[LM-vb]

⚠️ 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

NC 29.0.3

If a shared file or folder gets deleted, only the file or folder itself gets deleted yet its shares (entries in database) do not get deleted but remain orphaned. After the deletion, it is possible to open such a link, a password (if set) will be queried and only after a successful authentication an error page is shown (missing file resp. folder).

Steps to reproduce

1. Share an existing file or folder. Keep the link and password of the share.
2. Delete file or folder.
3. Link and password still work and redirect to an error page (as file resp. folder are missing).

Expected behavior

When deleting a shared file or folder, its meta data (shares, etc.) has to be deleted automatically, too.

Installation method

Community Manual installation with Archive

Nextcloud Server version

29

Operating system

Other

PHP engine version

PHP 8.3

Web server

Apache (supported)

Database engine version

PostgreSQL

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

Upgraded to a MAJOR version (ex. 28 to 29)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

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

Configuration report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "default_phone_region": "DE",
        "version": "29.0.3.4",
        "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "skeletondirectory": "",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "filelocking.enabled": true,
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "dbindex": 0,
            "timeout": 0
        },
        "session_lifetime": 3600,
        "session_keepalive": false,
        "tempdirectory": "***REMOVED SENSITIVE VALUE***",
        "remember_login_cookie_lifetime": 0,
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "maintenance": false,
        "theme": "",
        "loglevel": 2,
        "log.condition": {
            "apps": [
                "admin_audit"
            ]
        },
        "default_language": "en",
        "default_locale": "en_GB",
        "knowledgebaseenabled": false,
        "simpleSignUpLink.shown": false,
        "auth.webauthn.enabled": false,
        "updater.release.channel": "stable",
        "trashbin_retention_obligation": "auto, 30",
        "versions_retention_obligation": "auto, 30",
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "maintenance_window_start": 2
    }
}

List of activated Apps

Enabled:
  - activity: 2.21.1
  - admin_audit: 1.19.0
  - announcementcenter: 6.8.1
  - bruteforcesettings: 2.9.0
  - checksum: 1.2.4
  - cloud_federation_api: 1.12.0
  - comments: 1.19.0
  - contactsinteraction: 1.10.0
  - dav: 1.30.1
  - federatedfilesharing: 1.19.0
  - files: 2.1.0
  - files_automatedtagging: 1.19.0
  - files_downloadlimit: 2.0.0
  - files_pdfviewer: 2.10.0
  - files_reminders: 1.2.0
  - files_sharing: 1.21.0
  - files_trashbin: 1.19.0
  - files_versions: 1.22.0
  - files_zip: 1.5.0
  - impersonate: 1.16.0
  - logreader: 2.14.0
  - lookup_server_connector: 1.17.0
  - nextcloud_announcements: 1.18.0
  - notifications: 2.17.0
  - oauth2: 1.17.0
  - password_policy: 1.19.0
  - photos: 2.5.0
  - privacy: 1.13.0
  - provisioning_api: 1.19.0
  - quota_warning: 1.19.0
  - related_resources: 1.4.0
  - serverinfo: 1.19.0
  - settings: 1.12.0
  - sharebymail: 1.19.0
  - support: 1.12.0
  - survey_client: 1.17.0
  - systemtags: 1.19.0
  - theming: 2.4.0
  - twofactor_backupcodes: 1.18.0
  - updatenotification: 1.19.1
  - viewer: 2.3.0
  - workflowengine: 2.11.0
Disabled:
  - circles: 29.0.0-dev (installed 22.1.1)
  - contacts: 6.0.0 (installed 6.0.0)
  - dashboard: 7.9.0 (installed 7.0.0)
  - encryption: 2.17.0
  - federation: 1.19.0 (installed 1.10.1)
  - files_external: 1.21.0
  - firstrunwizard: 2.18.0 (installed 2.9.0)
  - recommendations: 2.1.0 (installed 0.8.0)
  - suspicious_login: 7.0.0
  - text: 3.10.1 (installed 3.1.0)
  - theming_customcss: 1.16.0 (installed 1.16.0)
  - twofactor_totp: 11.0.0-dev
  - user_ldap: 1.20.0
  - user_status: 1.9.0 (installed 1.0.1)
  - weather_status: 1.9.0 (installed 1.0.0)

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No response

Additional info

This issue has already been discussed in #7238, yet has been closed there for lack of response. For the time being, orphaned shares can be deleted on the command line via occ sharing:delete-orphan-shares

[solracsf]

These should be cleaned daily by a background job.
#43605

[LM-vb]

Do I need to set up a separate cron job (aside from cron.php) for that? Or a config setting?
Because there are orphaned shares on my instance which are older than 24 h.

[LM-vb]

Found the background job via occ background-job:list: OCA\Files_Sharing\DeleteOrphanedSharesJob. Last run is listed as 05:00:07 this morning. Which means that the cleaning definitely did not work, as some of the shares were orphaned yesterday.

If I understand the code in

server/apps/files_sharing/lib/DeleteOrphanedSharesJob.php

Line 23 in 3a97dbf

class DeleteOrphanedSharesJob extends TimedJob {

correctly, there are no preconditions to delete an orphaned share. And according to

server/apps/files_sharing/lib/DeleteOrphanedSharesJob.php

Line 91 in 3a97dbf

$this->logger->debug("{deleted} orphaned share(s) deleted", [

there is only a debug message logged (side note: I would have expected info instead of debug). Is there any other log where I can check what is (not) happening?

[LM-vb]

A diff of yesterday's and today's orphaned shares gave me the relevant hint: the orphaned shares only get deleted from the database if the relevant folders and files are permanently deleted. So as long as they are still present in the trash bin, the orphaned shares do not get deleted. Which makes sense insofar, as an accidently deleted file or folder gets restored, the share link gets restored, too.

[chaosgrid]

I am surprised you closed this bug report since while not cleaning up the orphaned share links might be correct, it is still a bug for other users as they still see a share (that they shouldn't actually see) when the file has been moved to the trashbin.

See nextcloud/groupfolders#1699

[LM-vb]

I closed the report, as my question/"bug" has been answered sufficiently (and my users can live with the error pages for a few days time, if they ever encounter one). However, I understand your point about the confusion if the share links point to nowhere in the time between being moved to the trash bin and permanently getting deleted.

And I would indeed recommend to you (in response to nextcloud/groupfolders#1699 (comment)) to open a bug report on the nextcloud/server github, as this seems to get more attention from the devs.

[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".