Server: Incomplete mounts table

[rullzer]

@icewind1991 last week you found an issue with the incomplete mount table.

I just upgraded my personal installation to the beta2. And was hit with the same issue (previews breaking, direct links failing). Only on my installation the files_sharing app was still enabled. Disabling and reenabling fixed the issue.

I have been unable to reproduce it since. But this is not good for UX.
Do we need a repair step or something?

CC: @LukasReschke

[icewind1991]

tried reproducing on clonecloud with no success

[LukasReschke]

That one is still super annoying. Did anyone had any progress here?

[blizzz]

are there also more details on

last week you found an issue with the incomplete mount table.

❓

[nickvergessen]

Happens on my instance as well, I can access /f/99797 but my wife can not, however she can manually click here way into /apps/files/?dir=/Bilder/Photos/2016/07-30&fileid=99797

But as soon as she refreshes the page there, she is redirected with "file does not exist".

Also on the public link she created you can not use the "download all" button, but you see the file list and everything just fine. I shared the same folder and it works all on my link.
Problem is https://github.com/nextcloud/server/blob/master/apps/files_sharing/lib/Controller/ShareController.php#L564 returns an empty array....

[schiessle]

On my instance I couldn't reproduce the issue. All shares continue to work. But as I shared a lot of pictures I noticed this issue:

If the recipient of a folder with images opens the folder he sees the file listing but no previews. What is probably OK because we first need to create them. The user can also download the images. So the share is fine and the user can access the file. If he clicks on the file to view it he gets this message: "Error! Could not generate preview of this file. Please go to the next slide while we remove this image from the slideshow". The folder was shared read-only, maybe this has something to do with the fact that the recipient can't generate the previews for the slideshow?

[schiessle]

But as soon as she refreshes the page there, she is redirected with "file does not exist".

I can reproduce this behavior. But before I refresh the page I can even download the pictures in the folder. 😕

[LukasReschke]

The folder was shared read-only, maybe this has something to do with the fact that the recipient can't generate the previews for the slideshow?

Yes. That was also broken on c.nc.c by this same bug – see https://github.com/nextcloud/server/issues/2297 and https://github.com/nextcloud/server/issues/2299

[schiessle]

Yes. That was also broken on c.nc.c by this same bug – see #2297 and #2299

So it looks like the mentioned PR didn't fixed it... Will try now to re-produce this on my dev environment

[LukasReschke]

So it looks like the mentioned PR didn't fixed it... Will try now to re-produce this on my dev environment

After ree-enabling sharing everything did as pointed out by @icewind1991 at https://github.com/nextcloud/server/pull/2299#issuecomment-262784461 – mind trying that after a DB backup?

But there was no follow-up or whatsoever on "why sharing needed to be reenabled"…

[nickvergessen]

On my instance I couldn't reproduce the issue. All shares continue to work.

Just for the record, the shares work, only the "download complete folder" button does not.

[nickvergessen]

Also sharing was neither disabled, nor did dis- and re-enabling help.

I posted the both share links on XMPP so you can see it in action

The exception is "Can not call getPath() on null" due to "Undefined index: 0" in https://github.com/nextcloud/server/blob/master/apps/files_sharing/lib/Controller/ShareController.php#L565

[schiessle]

I just checked the oc_mounts table on my instance and all entries have a valid user_id, so it seems to be a different issue then the one fixed by @icewind1991

... also rest of oc_mounts looks OK, correct paths, correct root_id,...

[nickvergessen]

Had a look, and for me the storage_id values are okay, while the entries of my wife are screwed with wrong values:

The colored entries are the same for both of us.
So they should have the same storage id, but they don't. I assume this is caused by an issue when writing the mounts table back in the update of 8.2 to 9, which would explain why productive instances are affected, while dev enviroments are not.

Of course I can manually adjust the storage Ids to fix this. But we should find out what went wrong and how to fix it.

[schiessle]

Right, I see the same but only for some shares, not for all... That's why I missed it the first time I looked at the table.

I still don't get when we screw them up? During the upgrade to 11? Or are they already wrong before but we only notice it now because we use this information in a different way with Nextcloud 11?

A repair step could look at all oc_mounts entries, lookup the storage in the oc_filecache for the "root_id" and set the same storage in oc_mounts... or do I miss something? cc @icewind1991

[icewind1991]

A repair step could look at all oc_mounts entries, lookup the storage in the oc_filecache for the "root_id" and set the same storage in oc_mounts... or do I miss something? cc @icewind1991

Sounds feasible

[nickvergessen]

Repair step in https://github.com/nextcloud/server/pull/2636

Is the creation logic still in our code somewhere and needs to be adjusted?

[nickvergessen]

The broken storage ids of my wife, are actually the shared::/*green* folder storages. So I guess when her mounts where written, it did something like "getById" and used thee first storage returned, instead of the actual root storage.

[nickvergessen]

It shouldn't happen for new mounts anymore. The current proposal is to have a repairstep to fix them all:
https://github.com/nextcloud/server/issues/2636
And additionally have some live verification to update the mount when the id changed (e.g. on cross storage move)
https://github.com/nextcloud/server/issues/2637

Please review ASAP