-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to delete LDAP remnants #9897
Comments
cc @nextcloud/ldap |
@Yomark1 it is not standard, but should not play a role. You use what happens on a |
Stumbled upon the same issue.
Additional info: User can be deleted, if LDAP-Mapping is cleared (LDAP DN empty in show-remnants) |
@blizz For sure, i did not claim this to be a workaround or anything more than just "additional info" from debugging the same issue on dev system. Also it includes the answer to your question to Yomark1 btw. |
@smuns sorry, I don't spot the answer? |
"sudo -u www-data php occ ldap:check-user $UID" results in "The user does not exists on LDAP anymore." |
@blizz : yes, I use the exact output. Thanks everyone for looking into this(and confirming the issue). |
We are experiencing the same issue. In our case we do a check-user to trigger the check. Afterwards the account shows up in the show-remnant output. If we immediately do the user:delete it will show "No user found". If we then wait a while (10+ minutes) and rerun the user:delete command, it will successfully delete the user. It seems there's a cache somewhere that is not cleared yet when we initially run the command. |
Yupp, it's a cache thing. And, if I remember correctly since I looked into, not straight forward solvable because there are different paths involved (resp. the required cache instance unvailable from that layer). |
We experienced this on 15.0.7 and then produced other problems like this: #11551 |
I'm closing this issue due to inactivity. If this is still happening please make sure to upgrade to the latest version. After that, feel free to reopen. |
We are running OwnCloud/Nextcloud for a long time now, and at the moment we have about 100 old employees that are deleted from LDAP but are still referenced in Nextcloud. We are running Nextcloud 13.04 now, but this issue is there for a long time. I believe this is a bug. At least for our particular LDAP configuration.
Steps to reproduce
Note: both "NextCloud name" and " LDAP UID" are samAccountName(LDAP) in our case . Not sure if this is standard.
Expected behaviour
User and data should be deleted like in the manual(https://docs.nextcloud.com/server/13/admin_manual/configuration_user/user_auth_ldap_cleanup.html) suggests.
Actual behaviour
Nothing changed. Data folder is still there. User is still shown in show-remnants, and occasionally shown in the nextcloud log files.
Server configuration
Operating system:
Ubuntu 16.04.4 LTS
Web server:
Apache/2.4.18 (Ubuntu)
Database:
mysqld 10.0.34-MariaDB-0ubuntu0.16.04.1
PHP version:
PHP 7.0.30-0ubuntu0.16.04.1
Nextcloud version: (see Nextcloud admin page)
13.04
Updated from an older Nextcloud/ownCloud or fresh install:
Yes, from Owncloud 7 or 8 to the current nextcloud applying most minor releases an all mayor releases.
Where did you install Nextcloud from:
Online download.
List of activated apps:
App list
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: local/smb/sftp/...
Yes, some SMB shares.
Are you using encryption: no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
LDAP
LDAP configuration (delete this part if not used)
LDAP config
Client configuration
Browser:
not relevant
Operating system:
Edit:
Typo's
The text was updated successfully, but these errors were encountered: