CODEWITHSUNDEEP
nextcloud
maples
maples

Reputation: 219

Nextcloud oc_storages table has multiple "local::" entries -- how to proceed?

I have a Nextcloud instance that I've been running for several years, and I'm preparing to move a large collection of photos and videos into it (which I've been previously managing with rsync). I came across this howto which gives relatively straightforward instructions that I feel comfortable with.

Before I started executing the steps in the howto, I took a look around to see if everything made sense. While doing that, I discovered that my oc_storages table has multiple local:: entries:

SELECT *
FROM oc_storages
WHERE id LIKE 'local::%';

screenshot of database query results showing three rows with different paths

The middle path (local::/srv/nextcloud/data/) is where Nextcloud currently resides on my system. It has previously been at the other two locations at various points in the history of this server. (Until today, I didn't realize that these paths were ever stored here!)

How do I clean up these old paths from the database?

I have not experienced any data loss when I moved my Nextcloud installation around in the past. All of my files are currently visible in Nextcloud, and I've successfully synced (nearly) all of them to a new laptop a few months ago. So Nextcloud definitely knows how to find the files on the disk.

Does this mean I can safely delete the two outdated rows from oc_storages, and all corresponding rows in oc_filecache?

Upvotes: 0

Views: 1120

Answers (1)

maples
maples

Reputation: 219

I ended up taking some backups and trying it out for myself :)

Long story short, yes, you can delete the bad oc_filecache and oc_storages rows.

However, I strongly recommend taking a backup of the oc_filecahce and oc_storages tables before doing so (duplicating the table within the database, like this question demonstrates). This way, if you break your Nextcloud instance, you can very easily copy over the rows you just deleted and try again. (I had to do this a few times!)

I neglected to document the exact steps and order which I deleted the rows, but at the end of the day, I had no rows in oc_storages or oc_filecache which had the storage ID of those old rows. There were additional other tables with file IDs on them that I checked. At least one of them had file IDs that were missing from oc_filecache after I purged the bad rows, so I deleted the mismatched rows from that table as well. I used mysqldump --no-data to dump the schema and ctrl+F for "file" in a text editor to find those tables.

Upvotes: 1

Related Questions