Shares disappearing over time after upgrade to 18.0.0

Hello there,

we are selfhosting a nextcloud instance with several hundred users.
On Friday we upgraded from 16.x to 18.0.0, so we are currently running the newest stable version available.

  • Nextcloud version (18.0.0):
  • Operating system and version (openSuse Leap):
  • Apache or nginx version (Apache/2.4.33):
  • PHP version (PHP 7.2.5):
  • we’re using 5 db-servers running mysql Ver 15.1 Distrib 10.3.20-MariaDB as a galera-cluster

After the upgrade we didn’t notice right away, but it brought problems, some users told us about on Monday: Shared folders did disappear in the accounts of the people those folders or files were shared with. The files/folders don’t disappear in the context of the owners. We’ve got a daily backup of our database, so we could have a look at the old ones (pre-upgrade). We found out, that the tables oc_share and oc_mounts are full in the old database (e.g. ~ 7000 entries for oc_share) but are quite empty in the current one (37 entries right now). This did however happen on Saturday, so right after the upgrade, the shares seem to still have been there.

For testing purposes, we did share a folder with each other yesterday, which seemed to work at first, but then disappeared a few hours later. We did try again, and this time, the share is still visible for the person, it’s shared with (around ~ 17 hours later). Anyway, we got the feedback from a user recently, that some of his new shares did disappear as well. So this still seems to be a current issue!

Now the first thing is: what could cause those entries in the database vanishing. We didn’t find anything suspicious in the database or the logfiles. I dont’t really know where to search. Is this a known behaviour somehow? Does this ring a bell to someone?

Secondly - after solving the issue of those shares disappearing - how can we restore the lost shares? Could we copy the lines from the old db-backup? Which tables would this be? oc_share, oc_mounts, …?
Is this even possible, or could the IDs make a mess, since it’s not sure they are unique anymore?

Thank you very much in advance
& best regards!

Hi @wiggum

I was just about to create a thread to warn about this issue. I was facing it myself and got a fix yesterday night.
The shares get deleted from the DB when a user removes a federated share. The “where” clause for the DB query was not correct.
This problem will be fixed in NC 18.0.1, but I suggest to implement the small code change yourself instantly to avoid continuous loss of the user’s shares. And the fix is simple:

I think restoring the shares is quite difficult. When files and mounts have changed (added, removed) then just restoring all shares from an earlier backup can cause some shares to point to non-existing files.
The safest would probably be a full restore of the backup - DB restore and file restore.
For my very small user base of just family members and a few friends, I was pretty sure, that nothing changed, so I just restored the oc_share table.
For me that worked fine.

Thank you very much, @Schmu, this was fast :slight_smile:

Conceirning the restore: It seems the table oc_share isn’t the only one affected. oc_mounts for example is a lot smaller now, too. And we tried this already: adding one of those disappeared lines from the old oc_share table in our new database doesn’t let the specified shared folder appear. I guess there’d be more tables to remigrate?

… and a full database restore would let newly uploaded files disappear, right?

Yes. The files would exist on the filesystem, but they wouldn’t show up in the web GUI or client apps.
Therefore, a full restore of database backup and file backup (both from the exact same time) would probably be the cleanest and safest.
The data loss for changed documents, contacts and calendar entries would be worst then.

It is possible, however, to restore the database and then scan all the files on the filesystem:
sudo -u http php /path/to/nextcloud/occ files:scan --all

Nextcloud would then add all new files to the database.
This would at least avoid the problem of restoring changed files and losing new files. However, there could be some shares that link to missing files afterward.

I’m not NC developer, so I cannot tell the best way to restore the data. Sorry :frowning:

Thank you so much @Schmu,

we merged oc_share, oc_mounts and oc_storages from our backup (with INSERT IGNORE) and then scanned the files with .../occ files:scan --all

Looks like it did work. The old shares are there again! And since we did that (on tuesday) we’ve got no new complaints about anything being broken!

1 Like

That’s great news! I’m glad you got the shares back.