Skip to content
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 User_LDAP user files/shares #4117

Closed
andrius-kulbis opened this issue Mar 28, 2017 · 12 comments · Fixed by #5689
Closed

Unable to delete User_LDAP user files/shares #4117

andrius-kulbis opened this issue Mar 28, 2017 · 12 comments · Fixed by #5689
Assignees
Milestone

Comments

@andrius-kulbis
Copy link
Contributor

Steps to reproduce

  1. Setup User_LDAP app to use LDAP backend
  2. Delete user from LDAP
  3. Delete user via occ user:delete

Expected behaviour

User, his all data and shares removed.

Actual behaviour

User is visible in ldap:show-remnants output.

If LDAP cache is expired and does not contain a deleted user anymore, the user:delete operation fails saying that the user does not exists (while his files and shares are still present). User shares become broken but visible (not able to access them or unshare them)

Server configuration

Operating system: Debian Jessie

Web server: Apache 2.4

Database: Mariadb 10

PHP version: 5.6.27

Nextcloud version: 11.0.2

Updated from an older Nextcloud/ownCloud or fresh install: updated

Where did you install Nextcloud from: updater

Are you using an external user-backend, if yes which one: LDAP

Nextcloud log (data/nextcloud.log)

Nextcloud log While accessing share of user deleted from ldap:
{"reqId":"QM4KjOpNF9hTWTdYc\/IK","remoteAddr":"127.0.0.1","app":"files","message":" Backends provided no user object for testuser","level":3,"time":"2017-03-28T11:06:07+00:00","method":"GET","url":"\/index.php\/apps\/files_texteditor\/ajax\/loadfile?filename=test.csv&dir=%2F","user":"user","version":"11.0.2.7"}
@blizzz blizzz self-assigned this Apr 3, 2017
@4001982248998
Copy link

I also might have that problem.

Checking a user account presence:

user@host:~$ occ ldap:check-user 621D38FD-13C8-4D18-9C8A-40E361ED2ABD
The user does not exists on LDAP anymore.
Clean up the user's remnants by: ./occ user:delete "621D38FD-13C8-4D18-9C8A-40E361ED2ABD"

Then trying to delete it:

user@host:~$ occ user:delete "621D38FD-13C8-4D18-9C8A-40E361ED2ABD"

                                                                    
  [OC\User\NoUserException]                                         
  621D38FD-13C8-4D18-9C8A-40E361ED2ABD is not a valid user anymore  
                                                                    

user:delete <uid>

Log excerpt:

{"reqId":"nTR4oUvYXrN6I0aTtt6h","level":3,"time":"2017-05-30T09:55:51+00:00","remoteAddr":"","user":"--","app":"PHP","method":"--","url":"--","message":"ldap_start_tls(): Unable to start TLS: Server is unavailable at \/var\/www\/nextcloud\/apps\/user_ldap\/lib\/LDAP.php#293","userAgent":"--","version":"12.0.0.29"}

The LDAP server is present, however, and LDAP logons possible.

@bcoory
Copy link

bcoory commented Jun 15, 2017

+1

@blizzz
Copy link
Member

blizzz commented Jul 11, 2017

Introduced by #2845

The early fetching of the home directory caused that one property was not set – this happens on deleteUser(). And caused an Exception to be thrown. It's stupid to depend on this behaviour however. I believe we have had this weird way to know that there is a delete operation, and avoid other cases… but if so, the case is not documented.

blizzz added a commit that referenced this issue Jul 11, 2017
homesToKill was not set in runtime since some changes some place else. It
required deleteUser() to be called first. The method acts independent of it
now.

Signed-off-by: Arthur Schiwon <[email protected]>
@blizzz
Copy link
Member

blizzz commented Jul 13, 2017

I believe we have had this weird way to know that there is a delete operation, and avoid other cases… but if so, the case is not documented.

Actually there is a test for it and it's a challenge…

blizzz added a commit that referenced this issue Jul 14, 2017
homesToKill was not set in runtime since some changes some place else. It
required deleteUser() to be called first. The method acts independent of it
now.

Signed-off-by: Arthur Schiwon <[email protected]>
@blizzz
Copy link
Member

blizzz commented Jul 14, 2017

Fix in #5689

@chasebolt
Copy link

running into this issue as well. nextcloud logging is constantly outputting errors about deleted ldap users and i have no way to delete them with occ.

blizzz added a commit that referenced this issue Aug 31, 2017
homesToKill was not set in runtime since some changes some place else. It
required deleteUser() to be called first. The method acts independent of it
now.

Signed-off-by: Arthur Schiwon <[email protected]>
@blizzz
Copy link
Member

blizzz commented Sep 4, 2017

@chasebolt

Fix in #5689

MorrisJobke added a commit that referenced this issue Sep 13, 2017
LDAP: simplify returning the homePath and fixing #4117
@MorrisJobke MorrisJobke removed this from the Nextcloud 12.0.4 milestone Sep 13, 2017
@MorrisJobke MorrisJobke added this to the Nextcloud 13 milestone Sep 13, 2017
blizzz added a commit that referenced this issue Sep 14, 2017
homesToKill was not set in runtime since some changes some place else. It
required deleteUser() to be called first. The method acts independent of it
now.

Signed-off-by: Arthur Schiwon <[email protected]>
rullzer added a commit that referenced this issue Sep 20, 2017
[stable12] LDAP: simplify returning the homePath and fixing #4117
@DP19
Copy link

DP19 commented Dec 3, 2017

I'm running into this issue. Setup LDAP which brought in all of my users before i narrowed it down to a group. Wanted to reconfigure the username mapping from UID to sAMAccountName so others could more easily share by searching usernames. Since it imported all of my users, they are already mapped to a UID internally.

When I run sudo -u apache php occ ldap:show-remnants it displays all of my users that are no longer in the correct group, but i can't delete them to get them in the correct ad group and map thier UID to username. It just gives me this error

[OC\User\NoUserException]
621D38FD-13C8-4D18-9C8A-40E361ED2ABD is not a valid user anymore

v 12.0.3

@blizzz
Copy link
Member

blizzz commented Dec 4, 2017

fix in 12.0.4

@colttt
Copy link

colttt commented May 2, 2018

nope..
I create a ldap user, the testuser shares something with me, I see it and can download it, so I delete the user in the LDAP. Now I can't download the shared file nor can delete the user:

select * from oc_ldap_user_mapping where ldap_dn like '%testnc%';                                                         
+-----------------------------------------+--------------------------------------+--------------------------------------+ 
| ldap_dn                                 | owncloud_name                        | directory_uuid                       | 
+-----------------------------------------+--------------------------------------+--------------------------------------+ 
| uid=testnc,cn<TOP-SECRET>de             | e4a20838-e232-1037-9768-a767f74b9486 | e4a20838-e232-1037-9768-a767f74b9486 | 
+-----------------------------------------+--------------------------------------+--------------------------------------+ 
1 row in set (0.01 sec)      

so the user is still in the database, but i can not find him:

./occ ldap:show-remnants | grep -i e4a20838-e232-1037-9768-a767f74b9486
./occ user:delete e4a20838-e232-1037-9768-a767f74b9486                                                                     
User does not exist

any ideas?

@colttt
Copy link

colttt commented May 3, 2018

ok, after a day it show me the user as remnants, and I can delete the user:

./occ ldap:show-remnants | grep -i e4a20838-e232-1037-9768-a767f74b9486
 e4a20838-e232-1037-9768-a767f74b9486 | test nc                    | testnc          | uid=testnc,cn<TOP-SECRET>de          | May 2, 2018|     | Y      |

./occ ldap:check-user e4a20838-e232-1037-9768-a767f74b9486                                                                 
The user does not exists on LDAP anymore.
Clean up the user's remnants by: ./occ user:delete "e4a20838-e232-1037-9768-a767f74b9486"

./occ user:delete "e4a20838-e232-1037-9768-a767f74b9486"
The specified user was deleted

How long must be a user deleted to show up as remnants?

@ahoward22
Copy link

I think this should answer your question. Simply because you deleted the user does not mean Nextcloud has queried your LDAP server...Take a look at this:

There are two prerequisites for LDAP User Cleanup to operate:

Set ldapUserCleanupInterval in config.php to your desired check interval in minutes. The default is 51 minutes.
All configured LDAP connections are enabled and operating correctly. As users can exist on multiple LDAP servers, you want to be sure that all of your LDAP servers are available so that a user on a temporarily disconnected LDAP server is not marked as deleted.
The background process examines 50 users at a time, and runs at the interval you configured with ldapUserCleanupInterval. For example, if you have 200 LDAP users and your ldapUserCleanupInterval is 20 minutes, the process will examine the first 50 users, then 20 minutes later the next 50 users, and 20 minutes later the next 50, and so on.

https://docs.nextcloud.com/server/12/admin_manual/configuration_user/user_auth_ldap_cleanup.html

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

Successfully merging a pull request may close this issue.

9 participants