Hi, I saw that if I transfer external share (smb) to another server maintaining the same mount in nextcloud and with same identical content (changing only the server that point) nextcloud always rescan all content and with cache using new id all favorites and user shares are lost.
Someone know if there is a way to avoid this or a safe way to “fix” user shares, if destination is still present and with same name and path even if with different id?
Another strange things saw recently is that logs have many records of background scan failed but if I did them manually complete without errors and I not understand what is the problem.
For example: User 07BA0395-A5D9-4DEF-918B-56DEACF96209 still has unscanned files after running background scan, background scan might be stopped prematurely
sudo -u www-data php -d memory_limit=2048M occ files:scan 07BA0395-A5D9-4DEF-918B-56DEACF96209
Starting scan for user 1 out of 1 (07BA0395-A5D9-4DEF-918B-56DEACF96209)
+---------+--------+-----+---------+---------+--------+--------------+
| Folders | Files | New | Updated | Removed | Errors | Elapsed time |
+---------+--------+-----+---------+---------+--------+--------------+
| 84651 | 508574 | 0 | 88 | 0 | 0 | 00:09:44 |
+---------+--------+-----+---------+---------+--------+--------------+
I had some background scan failed in past but with manual scan gave me exact error or backtrace that let me know the cause so I can solve it but lately the scans failed on several users and I can’t identify the cause.
Has anyone had a similar problem?
Thanks for any reply and sorry for my bad english.
The Basics
Nextcloud Server version (e.g., 29.x.x):
30
Operating system and version (e.g., Ubuntu 24.04):
Debian 12
Web server and version (e.g, Apache 2.4.25):
Apache
PHP version (e.g, 8.3):
8.2
Is this the first time you’ve seen this error? (Yes / No):
About user share I found a solution on latest smb share transferred on new server.
I wish I had thought of this earlier because of the many shares transferred before and not just to this last one but at least I avoided losing 248 user shares.
However, I have not found a solution to the other problem of background scans failing while manual ones do not.
I’m posting what I’ve done to fix user shares after transfer, if it can be useful to others, use with caution
Remap orphaned user shares after moving an external share to a new server and/or credentials
firstly after transferring all content scan only one user from occ (to generate new files id) and must remain unused and unscanned the others (to keep the old id)
SELECT numeric_id, id
FROM oc_storages
WHERE id LIKE ‘smb::%’;
find the storage IDs! Be careful, the old one could be multiple and barring any unforeseen circumstances, the largest one should be the correct one (in this case, there was also an ID 90 with the same credentials/destination).
Create a temp table (cleared when you log out) to map all old files id to new ones, ! replace the storage parameters
MariaDB [nextclouddb]> CREATE TEMPORARY TABLE fileid_map AS
→ SELECT old.fileid AS old_fileid, new.fileid AS new_fileid, old.path
→ FROM oc_filecache old
→ JOIN oc_filecache new
→ ON old.path = new.path
→ WHERE old.storage = 182 – old storage
→ AND new.storage = 286 – new storage
→ AND old.fileid <> new.fileid;
Query OK, 176952 rows affected (6 min 0,931 sec)
Records: 176952 Duplicates: 0 Warnings: 0
if you want to check if the table is present and the number of records, but you should already see it from the previous query, while if you stop it does not save the table
MariaDB [nextclouddb]> SELECT COUNT() FROM fileid_map;
±---------+
| COUNT() |
±---------+
| 176952 |
±---------+
1 row in set (0,026 sec)
replace all old id mapped in the temporary table with new ones
MariaDB [nextclouddb]> UPDATE oc_share s
→ JOIN fileid_map m ON s.file_source = m.old_fileid
→ SET s.file_source = m.new_fileid;
Query OK, 248 rows affected (0,135 sec)
Rows matched: 248 Changed: 248 Warnings: 0