Sabre\DAV\Exception\ServiceUnavailable: TypeError: Argument 1 passed to OCA\User_LDAP\Group_LDAP::walkNestedGroups() must be of the type string, null given #15050
Labels
Comments
k0ste
added
0. Needs triage
|
Workaround for this: I use |
|
@nextcloud/ldap #14464 as reference. It's not possible that |
|
The nulled else if(strtolower($this->access->connection->ldapGroupMemberAssocAttr) === 'memberuid') {
$result = $this->access->readAttribute($userDN, 'uid');
if ($result === false) {
\OCP\Util::writeLog('user_ldap', 'No uid attribute found for DN ' . $userDN . ' on '.
$this->access->connection->ldapHost, ILogger::DEBUG);
}
$uid = $result[0];( mind seeing whether applying diff --git a/apps/user_ldap/lib/Group_LDAP.php b/apps/user_ldap/lib/Group_LDAP.php
index cd4bd18cb4..b44a899db0 100644
--- a/apps/user_ldap/lib/Group_LDAP.php
+++ b/apps/user_ldap/lib/Group_LDAP.php
@@ -740,7 +740,7 @@ class Group_LDAP extends BackendUtility implements \OCP\GroupInterface, IGroupLD
\OCP\Util::writeLog('user_ldap', 'No uid attribute found for DN ' . $userDN . ' on '.
$this->access->connection->ldapHost, ILogger::DEBUG);
}
- $uid = $result[0];
+ $uid = $result['dn'][0];
} else {
// just in case
$uid = $userDN;fixes the issue? |
|
@blizz nope. |
|
Is this issue currently being addressed, or are there any workarounds? |
|
@k0ste thanks - I tried that, but I couldn't get it working. Was my approach wrong, or is my 16.0.1 installation simply incompatible with the 15.0.4 |
|
Ok, I was able to pull it off now.
This is obviously very hacky and I can't tell if there are any unexpected side-effects, but at least for me it works like this |
*edit* It fixes the access via Browser, however mobile apps still get a "500" error. Replacing user_ldap with 15.0.4 version does fix it entirely. So seems only a partial fix. log shows now:
|
|
Just as a hint I had the same problem and ishares from an old user in the database caused it after i deleted the shares it started working again |
would you mind to elaborate more what you did? Have you applied the proposed patch above? What elements did you delete from your DB? |
|
Sure, I did not try the patch above |
thx for sharing - in our case oc_share don't contain any non-existing users - so likely there are more such cases that can cause dn to be empty. Need to learn how to debug that. |
|
Today we got bitten by this too. Rolling back to 15.0.4 fixed the issue. |
|
I copied the "user_ldap" from the backup of 15.0.5 to the current 16 and made the changes that @hdrael suggested. LDAP now works again. |
|
potential fix in #18030 |
|
Closing this as fixed in #18030, being shipped with next maintenance updates |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce
Expected behaviour
Users get files explorer.
Actual behaviour
After login user can't do anything.
Server configuration
Operating system: Linux 5.0.7
Web server: nginx 1.15.11
Database: PostgreSQL 10.3
PHP version: 7.3.4
Nextcloud version: 15.0.7
Updated from an older Nextcloud/ownCloud or fresh install: Upgrade
Where did you install Nextcloud from: 15.0.4
Signing status:
Signing status
List of activated apps:
App list
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: local + s3
Are you using encryption: no
Are you using an external user-backend, if yes which one: OpenLDAP
LDAP configuration (delete this part if not used)
LDAP config
Client configuration
Browser: Firefox 66.0.2
Operating system: Linux 5.0.7
Logs
Web server error log
Web server error log
Nextcloud log (data/nextcloud.log)
Nextcloud log
The text was updated successfully, but these errors were encountered: