[Bug]: Ghost folder reappears after removing SMB external storage due to stale oc_filecache entries

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

I encountered a strange issue after removing an SMB/CIFS external storage mount.

The SMB folder was previously mounted and visible to the user AdminMark01. After removing the SMB mount from Nextcloud, the folder continued to reappear in the Files app even after deleting it from the web interface.

The affected folder was:

Ponomareva_Nadejda

The issue affected only one user: AdminMark01.

Running "php occ files:cleanup" and "php occ files:scan AdminMark01" did not permanently solve the issue.

After investigating the database, I found stale entries remaining in oc_filecache. Those entries belonged to home::AdminMark01 even though the original SMB mount had already been removed.

Steps to reproduce

1. Create an SMB/CIFS external storage mount.
2. Access the SMB folder using a user account.
3. Remove the SMB external storage from Nextcloud administration.
4. Delete the folder if it still appears in Files.
5. Run:
   php occ files:cleanup
   php occ files:scan AdminMark01
6. Observe that the folder reappears.
7. Query oc_filecache and observe stale entries associated with home::AdminMark01.

Expected behavior

After removing an SMB/CIFS external storage mount, all related filecache entries should be cleaned automatically.

The removed folder should never reappear in the user's Files app.

The removed SMB folder kept reappearing.

No matching entries existed in oc_external_mounts or oc_mounts.

However, stale entries remained in oc_filecache and were associated with:

home::AdminMark01

As a result, Nextcloud treated the removed SMB folder as a normal folder in the user's home storage.

Nextcloud Server version

33

Operating system

Other

PHP engine version

PHP 8.4

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": {
    "htaccess.RewriteBase": "/",
    "memcache.local": "\\OC\\Memcache\\APCu",
    "upgrade.disable-web": true,
    "dbtype": "mysql",
    "version": "33.0.5.1",
    "dbtableprefix": "oc_",
    "mysql.utf8mb4": true,
    "installed": true,
    "overwriteprotocol": "https",
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "redis": {
      "host": "***REMOVED SENSITIVE VALUE***",
      "port": 6379
    },
    "loglevel": 4,
    "default_phone_region": "DE",
    "default_locale": "de_DE",
    "default_language": "ru",
    "maintenance": false,
    "mail_smtpmode": "smtp",
    "mail_sendmailmode": "smtp",
    "mail_smtpport": 465,
    "mail_smtpsecure": "ssl",
    "mail_smtpauth": true,
    "skeletondirectory": "",
    "simpleSignUpLink.shown": false,
    "enable_file_conversion": true,
    "defaultapp": "files,external_index1,announcementcenter",
    "knowledgebaseenabled": false,
    "twofactor_enforced": "false",
    "forbidden_filename_characters": [
      "<",
      ">",
      ":",
      "\"",
      "|",
      "?",
      "*",
      "\\",
      "/"
    ]
  }
}

List of activated Apps

Enabled:
  - activity: 6.0.0
  - admin_audit: 1.23.0
  - announcementbanner: 2.4.2
  - announcementcenter: 7.4.1
  - bruteforcesettings: 6.0.0
  - dav: 1.36.0
  - external: 8.0.1
  - files: 2.5.0
  - files_external: 1.25.1
  - files_sharing: 1.25.2
  - files_trashbin: 1.23.0
  - files_versions: 1.26.0
  - forms: 5.3.1
  - groupfolders: 21.0.7
  - guests: 4.7.5
  - previewgenerator: 5.13.0
  - richdocuments: 10.2.0
  - twofactor_totp: 15.0.0

Nextcloud Signing status

Nextcloud Logs

No relevant Nextcloud log entries were found during the investigation.

The issue was identified through database analysis rather than server logs.

The affected ghost folder repeatedly reappeared without corresponding errors in the Nextcloud log.

Additional info

System:

• QNAP TS-264
• QNAP QTS
• Docker / Container Station
• Nextcloud Hub 26 Winter (33.0.5)
• Nextcloud version: 33.0.5.1
• MariaDB 10.11
• Default user backend (database)
• Server-side encryption disabled

Investigation summary:

The affected folder was originally an SMB/CIFS external storage mount named:

Ponomareva_Nadejda

The issue affected only one user:

AdminMark01

Investigation showed that the removed SMB mount no longer existed.

The following queries returned no results:

SELECT * FROM oc_external_mounts WHERE mount_point LIKE '%Ponomareva%';

SELECT * FROM oc_mounts WHERE mount_point LIKE '%Ponomareva%';

However, stale entries remained in oc_filecache.

Example paths:

files/Ponomareva_Nadejda
files/Ponomareva_Nadejda/@Recycle
files/Ponomareva_Nadejda/...

Approximately 110-116 entries were found.

The storage mapping query showed:

numeric_id | id
1 | home::AdminMark01

This indicates that stale filecache entries originating from the removed SMB mount had become associated with the user's home storage.

The issue could not be permanently resolved using:

php occ files:cleanup
php occ files:scan AdminMark01

The ghost folder disappeared only after manually removing the stale entries from oc_filecache:

DELETE FROM oc_filecache
WHERE storage = 1
AND path LIKE 'files/Ponomareva_Nadejda%';

followed by:

php occ files:scan AdminMark01

After that, the folder no longer reappeared.

The issue does not name source files or tests. Start by tracing removal of SMB/CIFS external storage and the filecache cleanup path, then reproduce the sequence with the listed occ commands and inspect the relevant database records. Done means removing a mount also removes its filecache entries and the folder does not reappear after scanning.