⚠️ This issue respects the following points: ⚠️
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
- Create an SMB/CIFS external storage mount.
- Access the SMB folder using a user account.
- Remove the SMB external storage from Nextcloud administration.
- Delete the folder if it still appears in Files.
- Run:
php occ files:cleanup
php occ files:scan AdminMark01
- Observe that the folder reappears.
- 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?
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.
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
php occ files:cleanup
php occ files:scan 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?
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
Nextcloud Signing status
Nextcloud Logs
Additional info
System:
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.