Domain user cannot access files via Web or Client, or WebDAV - Invalid recipient #26683
Comments
|
For example is a user is receiving two shares with the name "test", at the time ownCloud sets up the filesystem it will rename one of the received shares to "test (2)" by calling @turin13 can you provide more information about the sharing scenario for the affected users ? |
|
@PVince81 Thank you for the reply. |
|
Check Then do a |
|
I did the examination as you suggested. |
|
Any updates, guys? I think I provided the info. If something else is needed just let me know. |
|
Line 826 is here: https://github.com/owncloud/core/blob/v9.1.2/lib/private/Share20/Manager.php#L862 Some things that we can deduce from this information:
So maybe the user received a share directly and also through a group and then later was removed from that group. |
|
I tried to reproduce a similar situation but couldn't. This is because for some reason when fetching the user's received shares, my env doesn't return the group shares for groups in which the user does not belong to any more. Somehow on your env it seems that there is an inconsistency: the API fetches all received shares including some group shares where the user doesn't belong in the group any more. Then when trying to group these shares to display only a single received folder, it tries to normalize the target folder name but fails because a check finds out that the user is not in the group share's group any more. I'm now thinking of a possible quickfix that prevents fixing file_target for group shares in this specific routine. |
|
Hmm, I looked a bit in the LDAP code. What I observed is that:
Now from what I see the LDAP code is slightly different in both methods. From what I see the cache key is different for both, one starts with "inGroup" the other with "getUserGroups". So there is a slight chance that both caches are telling a different story and causing this weird inconsistency. |
|
Now here I really wonder why @jvillafanez do you know anything about this ? Is there an easy way to clear the LDAP caches ? @owncloud/ldap |
|
Raised owncloud/user_ldap#30 to clarify the general issue for this code inconsistency. |
|
@turin13 I see you have a memcache set up. Also browsing through the LDAP code shows that the cache it uses is also memcache. So it is likely that there is an inconsistency about group membership in the cache. Are you able to clear the memcache ? (not sure how, I have no experience with it) |
|
From what I see here And then just now as this special code path calls I'm trying to reproduce this locally in some way. |
|
Note: it is close to impossible to inspect the cache keys without using a debugger and let the method generate the key name for you. Steps to reproduce:
At this point And then 💥 It is very likely that this discrepancy could happen in other code paths where one uses |
|
In this very specific scenario, the PROPFIND still succeeds but zombie400 cannot see the share at all, even though there is a valid user share for that user. This is because the exception is caught and the mount point is discarded. Quickfix: clear all LDAP-related memcache keys! |
|
Good evening PVince81, |
|
And also, if it's related to share, why I can't scan user's files? I mean all of them (using php occ files:scan UID). |
|
"No change" meaning you're still getting the same exception with exact same message ? Not sure why you can't scan, what error does the scanner give you for these users ? |
This is the scanning result:
This is the Login error log: |
|
Ok thanks. If despite cleaning the memcache the problem still occurs, there is something fishy with the LDAP implementation or with the LDAP queries. I'm not sure if both |
|
Hi, |
|
The oc_mounts table isn't authoritative, it's currently just like a cache. If you'd delete entries there they'd appear again the next time the user's FS is setup. In the case of your users experiencing the problem, the code never reaches the part where it actually adds the entries into that table. It should be possible to provide a quick workaround for these users to be able to bypass that exception. However my worry is that the LDAP API results inconsistency is likely to cause you other kinds of unpredictable trouble in the future. Ideal would be to find out why it happens. @turin13 what LDAP server are you using ? Can you post your LDAP config dump ? |
|
@PVince81 we're using Active Directory with all DCs 2012R2 and the same functional level of the domain. |
|
Guys, any news? What do you think I can do to workaround this issue? May I somehow reset those users in ownCloud (without deleting them from Active Directory)? |
|
I'm out of ideas and don't have enough experience with LDAP to be able to debug this further. Let me provide you with a quick patch to bypass the code in question. |
|
Comment out this piece: diff --git a/apps/files_sharing/lib/MountProvider.php b/apps/files_sharing/lib/MountProvider.php
index 54f9fea..92f377e 100644
--- a/apps/files_sharing/lib/MountProvider.php
+++ b/apps/files_sharing/lib/MountProvider.php
@@ -165,11 +165,13 @@ class MountProvider implements IMountProvider {
$permissions = 0;
foreach ($shares as $share) {
$permissions |= $share->getPermissions();
+ /*
if ($share->getTarget() !== $superShare->getTarget()) {
// adjust target, for database consistency
$share->setTarget($superShare->getTarget());
$this->shareManager->moveShare($share, $user->getUID());
}
+ */
}
$superShare->setPermissions($permissions);This is in the method This will prevent the code to try and fix the share's target. There is a slight chance that the users might see duplicate received shares. But that's better than not being able to login at all. |
|
I implemented your patch and upon Apache restart was able to login as affected user. Then I saw some shares with strange behavior - nothing was mentioned on "Shared with me" page. |
|
Hmmmm... that behavior is still mysterious. From my understanding removing the patch should bring back the issue. But maybe some other piece of code fixed the files_target when the users were able to login. |
|
If I could help you by providing additional info, so that ownCloud will develop protection against such cases, I'll do this gladly. |
|
I can't think of any info that could help here. From my understanding the issue was caused by the LDAP APIs (or the LDAP server ?) to return inconsistent results when calling the "is user in group" and "get user memberships" functions. But maybe it's something else and what we observed is just a side effect. |
|
but thanks anyway 😄 |
|
I had another try reproducing this but without luck. In your specific setup I don't understand how this issue can happen with an already cleared cache. Anyway, we find other cases where inconsistent cache results could cause |
|
If there's any info I can provide, I'll be happy to do so. |
|
please try with #26871 |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Steps to reproduce
Expected behaviour
Normal login and access to the files
Server configuration
Operating system:
Ubuntu 14.04 x86_64
Web server:
Apache/2.4.7 (Ubuntu)
Database:
MySQL Distrib 5.5.53, for debian-linux-gnu on x86_64
PHP version:
PHP 5.5.9-1ubuntu4.20
Zend Engine v2.5.0
ownCloud version: (see ownCloud admin page)
ownCloud 9.1.2 (stable)
Updated from an older ownCloud or fresh install:
Update from previous major version (done several tymes)
Where did you install ownCloud from:
Ubuntu repository (deb)
Signing status (ownCloud 9.0 and above):
No errors have been found.
List of activated apps:
The content of config/config.php:
Are you using encryption:
No
Are you using an external user-backend, if yes which one:
ActiveDirectory
Logs
ownCloud log (data/owncloud.log)
The text was updated successfully, but these errors were encountered: