Received share to local user disappears from Webdav when LDAP server unavailable #20536

Closed
PVince81 opened this Issue Nov 16, 2015 · 8 comments

Projects

None yet

4 participants

@PVince81
Collaborator

Steps

  1. Setup OC with a local admin user "root"
  2. Setup LDAP with zombies
  3. Login as "zombie1"
  4. Create a folder "test" with some files inside
  5. Share "test" with "root"
  6. Log out
  7. Run curl -X PROPFIND http://root:admin@localhost/owncloud/remote.php/webdav/ | xmllint --format -, check that the result contains the folder "test" => it does
  8. Turn off the LDAP server (I stopped the docker instance)
  9. Run the same command again, check if the folder "test" is there.

Expected result

Either Webdav fails completely or the folder "test" appears still, but a PROPFIND on it should return "503 Storage not available".

Actual result

The folder "test" disappears from the Webdav result, which could cause the sync client to delete it locally. A PROPFIND on the folder directly gives a 404.

Versions

Observed in OC 8.1.4 and master (9.0 pre-alpha).

Note: this might be an edge case as we're sharing files between LDAP users and non-LDAP users.

@blizzz @Xenopathic @icewind1991

@PVince81
Collaborator

CC @MorrisJobke in case you ever observed something similar

@MorrisJobke
Member

CC @MorrisJobke in case you ever observed something similar

o.O This was usually fixed by the famous PR #15332

@PVince81
Collaborator

Yes, except that here it is special: the current user is not a LDAP user. However the received shares are from LDAP users. So maybe there's a missing exception to be thrown in that case.

@blizzz
Contributor
blizzz commented Nov 16, 2015

In that case, an LDAP interaction does not happen. Either it might be that the code path does not check for user existance and no need to get home of the sharee (not sure how the location is determined). Or, those were cached from a previous attempt, @PVince81? Can you retry after setting cache life time to 0 in LDAP advanced settings?

@PVince81
Collaborator

With the cache ttl set to 0 I get the same behavior on stable8.2.

@blizzz blizzz added this to the 9.0.1-next-maintenance milestone Mar 1, 2016
@blizzz
Contributor
blizzz commented Mar 1, 2016

I put it on 9.0.1 for further investigation.

@blizzz
Contributor
blizzz commented Mar 3, 2016

@PVince81 so i reproduced it (except a case where the LDAP was inside a vpn. closing the connection only ended up in a timeout), however I do not think the solution is to be sought in LDAP. Any external user backend would be affected by this, thus a general solution is thought.

Anyway, the ServerNotAvailable Exception is thrown, but caught in base.php, which just writes it to the log file. Opening a PR to discuss it.

@blizzz
Contributor
blizzz commented Mar 3, 2016

Check out #22800

This however would just totally fail not only WebDAV but the web login just as well. With some more digging, we might make it possible to only take out affected files with a proper error code (OTOH this might be confusing for the user just as well, but at least other components would be working). But it is the only time the Exception is thrown and without further context info (user, file) making it hard to do everything right. Probably the shared storaged would need to take care about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment