All non-binary documents vanished after upgrade to 5.4, only top level folders left

[joseph]

@kqcav ok, so atleast we know this is some nextcloud issue...

This usually comes down to the nextcloud apps you have installed . Can you disable some of those apps one by one and try ? https://docs.cloudron.io/apps/nextcloud/#fixing-a-broken-install

[kqcav]

So, I was indeed able to restore yesterday's NC in version 30.0.5 on app version 4.23.4 by cloning, and this shows all data + files and also allows login.

I was also able to localize the responsible NC plugin: turns out it was not an active plugin, but one disabled by the upgrade process: user_ldap
Identified this by comparing the plugin lists in 4.23.4/30.0.5 and 5.4.0/31.0.1.

After re-enabling user_ldap, all documents und subfolders were visible in NextCloud 31.0.1, too.

I suppose there was good reason for disabling it.
But at least one step seems to be missing in the shift from ldap to oidc.

Thanks again, Joseph, your support was very helpful!
/Chris

[joseph]

So, if you login via LDAP it works but if you login via OIDC button it doesn't work?

[kqcav]

I don't know, frankly speaking.
We only login via Browserform provided by NextCloud – before & after the upgrade. (cf. Screenshot)

For years, I used to be under the impression, these user accounts are somehow stored in a NC database or something like that, but last autumn I realized that our cloudron accounts are used. So I guess this is done via ldap?

Confusing thing this morning was that loging in via the button ›Login with Cloudron‹ granted access, but without giving the files.

[joseph]

@kqcav said in All non-binary documents vanished after upgrade to 5.4, only top level folders left:

For years, I used to be under the impression, these user accounts are somehow stored in a NC database or something like that, but last autumn I realized that our cloudron accounts are used. So I guess this is done via ldap?

yes, nextcloud is using ldap to authenticate as cloudron account. but oidc is also the same but using oidc protocol. The LDAP setup will go away at some point. So, it would be good to understand why this is not working

[kqcav]

Provided some guidance, I could assist with some debugging, logfiles, configuration excerpts.
I have two copies of the NC installation still there, but switched off – I could mess around in them without any disturbance or costs.

In the running NC instance, OIDC seems to be configured, all 9 environment variables are given and have reasonable values, which are mentioned in https://docs.cloudron.io/packaging/addons/#oidc
curling the endpoints works, response is valid JSON at first glance.

Do I need to verify in the user accounts in the Cloudron master?

[nebulon]

Initially I thought maybe the user mapping would be off. Basically LDAP users in your instance won't get matched correctly by Nextcloud with the equivalent OpenID user, however after rereading this thread, you indicate that folders to exist but just no files, yet those files are in the filestore? If you use other nextcloud plugins/apps in those instances, do they have the data?

[kqcav]

Interestingly (and annoyingly) our current NextCloud-Instance was not working again this morning, meaning that login was only possible via the „login with cloudron“redirection and that subfolders & documents were missing. The reason: user_ldap was disabled again …

Obviously NC was automatically upgraded to release 31.0.2 last night, and user_ldap got disabled in the process.
I have disabled auto-updates for now.

So I can confirm that this is the reason for our „document loss“.

And yes, it looks like the connection from OpenID-authenticated users to NC documents + folders gets lost somehow/somewhere.
But it's not the case that there are „extra user accounts“ in NextCloud. They are the same (same name, same, password, same 2fa) before & after activation of user_ldap.

I don't know how permissions are implemented „under the hood“ in NC.
We grant r/w access based on a group („staff“), not on a user base.

I noted one difference between „with / without user_ldap“:
the „owner“ of the folders is slightly different:
With user_ldap enabled, it's the full name „Christian A Vogl“, whereas when it's disabled, it's the short login name „cav“. Maybe a hint, that some data fetching from the Cloudron master did not succeed, and maybe the same data fetching action that should get the user's groups?

PS:
We do not use other plugins or apps in NC. But I could test one or the other, if you think that might help finding the cause.

[nebulon]

so maybe the user to groups mapping isn't working as expected within Nextcloud then? Do you have a way to verify that in your instance?

[kqcav]

Probably I have – whatever is visible in the NC admin interface is available.
Are you suggesting that I should disable user_ldap again and check?

But isn't the question rather this:

Given the fact that the user-group mapping is available in NC as soon as I enable user_ldap, isn't this a hint on „no cause in NC, but rather in the Cloudron mothernship“ (this being the OpenID provider)?
No update, no restart, just enabling user_ldap and login – even „on the fly“.

[kqcav]

But in a way you're up to something:
This group ›staff‹ is only defined in Cloudron, not in NC.

Maybe user_ldap also fetches group assignments from Cloudron no matter if defined in NC, wheras ›OpenID connect user backend‹ only fetches those available in the app / in NC.

I'll try that.

[kqcav]

No, that did not resolve the problem,
even if ›staff‹ is also a group in NC and the users are assigned to that group,
our files & folders (below top level) do not show up in the NC interface.

[kqcav]

Also:
independent of group assignments, NC doesn't even show a user's own files (but it probably should, shouldn't it?)