9.1.7 occ user:delete fails with moved users #30170

manderson-it · 2018-01-17T11:55:04Z

Steps to reproduce

Have 9.1.7 installed by repo (Ubuntu 16.04) with connected OpenLDAP
Move some users in OpenLDAP from one OU to another (still under the same base tree).
Show LDAP remnants sudo -u www-data php occ ldap:show-remnants
It shows the moved users as remnants.
Try to delete those remnants with sudo -u www-data php occ user:delete userid (userid here is a placeholder, I can successfully delete users that have been deleted in OpenLDAP)
It displays: The specified user could not be deleted. Please check the logs.
/var/log/owncloud.log shows (Userids are anonymized but are actually displayed in the log with the underscore followed by a number.

{"reqId":"7JOt4iqW9S4LarwQuhb4","remoteAddr":"","app":"user_ldap","message":"User userida_5590 is not marked as deleted, not cleaning up.","level":1,"time":"2018-01-17T12:36:06+01:00","method":"--","url":"--","user":"--"}
{"reqId":"\/V1AzzrNp3wSf1RJIjq2","remoteAddr":"","app":"user_ldap","message":"User useridb_7998 is not marked as deleted, not cleaning up.","level":1,"time":"2018-01-17T12:36:09+01:00","method":"--","url":"--","user":"--"}

Can you help to resolve this?

Expected behaviour

(a) Don't show the user under ldap:remnants when it is not actually deleted. The OpenLDAP user has only been moved to a different OU under the same base.
(b) Should output more helpful error messages as actually shown in the log file.

Actual behaviour

Deleting shown remnants with sudo -u www-data php occ user:delete
just displays: The specified user could not be deleted. Please check the logs.
/var/log/owncloud.log shows this (Userids are anonymized but are actually displayed in the log with the underscore followed by a number.

{"reqId":"7JOt4iqW9S4LarwQuhb4","remoteAddr":"","app":"user_ldap","message":"User userida_5590 is not marked as deleted, not cleaning up.","level":1,"time":"2018-01-17T12:36:06+01:00","method":"--","url":"--","user":"--"}
{"reqId":"\/V1AzzrNp3wSf1RJIjq2","remoteAddr":"","app":"user_ldap","message":"User useridb_7998 is not marked as deleted, not cleaning up.","level":1,"time":"2018-01-17T12:36:09+01:00","method":"--","url":"--","user":"--"}

Server configuration

Operating system: Ubuntu 16.04

Web server: Apache 2.4.20

Database: mysql 5.7.20

PHP version: 7.0.22-0ubuntu0.16.04.1

ownCloud version: 9.1.7

Updated from an older ownCloud or fresh install: yes

Where did you install ownCloud from: official repo http://download.owncloud.org/download/repositories/9.1/Ubuntu_16.04

Signing status (ownCloud 9.0 and above): what?

The content of config/config.php:

sudo -u www-data php occ config:list system
ownCloud is in maintenance mode - no app have been loaded
{
    "system": {
        "instanceid": "5370757274b63",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "\/var\/www\/owncloud\/data",
        "dbtype": "mysql",
        "theme": "",
        "maintenance": true,
        "trusted_domains": [
            "***FQDN REMOVED SENSITIVE VALUE***",
            "IP ***REMOVED SENSITIVE VALUE***"
        ],
        "dbname": "owncloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "ldapIgnoreNamingRules": false,
        "log_type": "errorlog",
        "loglevel": 3,
        "logfile": "\/var\/log\/owncloud\/teamcloud.log",
        "logtimezone": "Europe\/Berlin",
        "default_language": "de_DE",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "trashbin_retention_obligation": "30, auto",
        "memcached_server": [
            "localhost",
            11211
        ],
        "maxZipInputSize": 1073741824,
        "allowZipDownload": true,
        "forcessl": true,
        "mail_smtpmode": "smtp",
        "mail_from_address": "linuxadmin",
        "mail_smtphost": "FQDN ***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "version": "9.1.7.2",
        "updater.secret": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "tls",
        "updatechecker": false,
        "memcache.local": "\\OC\\Memcache\\APC"
    }
}

List of activated apps:

sudo -u www-data php occ app:list
Enabled:
  - comments: 0.3.0
  - configreport: 0.1.1
  - dav: 0.2.7
  - federatedfilesharing: 0.3.0
  - federation: 0.1.0
  - files: 1.5.1
  - files_antivirus: 0.9.0.1
  - files_external: 0.6.0
  - files_pdfviewer: 0.8.1
  - files_sharing: 0.10.0
  - files_texteditor: 2.1
  - files_trashbin: 0.9.0
  - files_videoplayer: 0.9.8
  - provisioning_api: 0.5.0
  - systemtags: 0.3.0
  - templateeditor: 0.1
  - updatenotification: 0.2.1
  - user_ldap: 0.9.0
Disabled:
  - activity
  - calendar
  - contacts
  - documents
  - encryption
  - external
  - files_versions
  - firstrunwizard
  - gallery
  - notifications
  - tasks
  - user_external

Are you using external storage, if yes which one: smb

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)

+-----------+-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| appid     | configkey                         | configvalue                                                                                                                        |
+-----------+-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
| user_ldap | cleanUpJobOffset                  | 0                                                                                                                                  |
| user_ldap | enabled                           | yes                                                                                                                                |
| user_ldap | enforce_home_folder_naming_rule   |                                                                                                                                    |
| user_ldap | has_memberof_filter_support       |                                                                                                                                    |
| user_ldap | home_folder_naming_rule           | attr:uid                                                                                                                           |
| user_ldap | installed_version                 | 0.9.0                                                                                                                              |
| user_ldap | last_jpegPhoto_lookup             | 0                                                                                                                                  |
| user_ldap | ldap_agent_password               | SENSITIVE                                                                                                                       |
| user_ldap | ldap_attributes_for_group_search  |                                                                                                                                    |
| user_ldap | ldap_attributes_for_user_search   |                                                                                                                                    |
| user_ldap | ldap_backup_host                  | SENSITIVE                                                                                                           |
| user_ldap | ldap_backup_port                  | 636                                                                                                                                |
| user_ldap | ldap_base                         | dc=SENSITIVE,dc=SENSITIVE,dc=de                                                                                                        |
| user_ldap | ldap_base_groups                  | ou=Groups,dc=SENSITIVE,dc=SENSITIVE,dc=de                                                                                              |
| user_ldap | ldap_base_users                   | ou=Users,dc=SENSITIVE,dc=SENSITIVE,dc=de                                                                                               |
| user_ldap | ldap_cache_ttl                    | 300                                                                                                                                |
| user_ldap | ldap_configuration_active         | 1                                                                                                                                  |
| user_ldap | ldap_display_name                 | cn                                                                                                                                 |
| user_ldap | ldap_dn                           | uid=SENSITIVE,ou=System,ou=Users,dc=SENSITIVE,dc=SENSITIVE,dc=de                                                                    |
| user_ldap | ldap_dynamic_group_member_url     |                                                                                                                                    |
| user_ldap | ldap_email_attr                   | mail                                                                                                                               |
| user_ldap | ldap_experienced_admin            | 0                                                                                                                                  |
| user_ldap | ldap_expert_username_attr         | uid                                                                                                                                |
| user_ldap | ldap_expert_uuid_group_attr       |                                                                                                                                    |
| user_ldap | ldap_expert_uuid_user_attr        |                                                                                                                                    |
| user_ldap | ldap_group_display_name           | cn                                                                                                                                 |
| user_ldap | ldap_group_filter                 | (&(|(objectclass=posixGroup))(|(cn=group1)(cn=group2)(cn=group3)(cn=group4))) |
| user_ldap | ldap_group_filter_mode            | 1                                                                                                                                  |
| user_ldap | ldap_group_member_assoc_attribute | memberUid                                                                                                                          |
| user_ldap | ldap_groupfilter_groups           | group1
group2
group3
group4
|
| user_ldap | ldap_groupfilter_objectclass      | posixGroup                                                                                                                         |
| user_ldap | ldap_host                         | SENSITIVE                                                                                                          |
| user_ldap | ldap_login_filter                 | (&(|(objectclass=posixAccount))(uid=%uid))                                                                                         |
| user_ldap | ldap_login_filter_mode            | 1                                                                                                                                  |
| user_ldap | ldap_loginfilter_attributes       |                                                                                                                                    |
| user_ldap | ldap_loginfilter_email            | 0                                                                                                                                  |
| user_ldap | ldap_loginfilter_username         | 1                                                                                                                                  |
| user_ldap | ldap_nested_groups                | 0                                                                                                                                  |
| user_ldap | ldap_override_main_server         | 0                                                                                                                                  |
| user_ldap | ldap_paging_size                  | 0                                                                                                                                  |
| user_ldap | ldap_port                         | 389                                                                                                                                |
| user_ldap | ldap_quota_attr                   |                                                                                                                                    |
| user_ldap | ldap_quota_def                    |                                                                                                                                    |
| user_ldap | ldap_tls                          | 1                                                                                                                                  |
| user_ldap | ldap_turn_off_cert_check          | 0                                                                                                                                  |
| user_ldap | ldap_user_display_name_2          |                                                                                                                                    |
| user_ldap | ldap_user_filter_mode             | 1                                                                                                                                  |
| user_ldap | ldap_userfilter_groups            |                                                                                                                                    |
| user_ldap | ldap_userfilter_objectclass       | posixAccount                                                                                                                       |
| user_ldap | ldap_userlist_filter              | (|(objectclass=posixAccount))                                                                                                      |
| user_ldap | types                             | authentication                                                                                                                     |
| user_ldap | use_memberof_to_detect_membership | 1                                                                                                                                  |
+-----------+-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------+

Client configuration

Browser: Version 63.0.3239.132

Operating system: Windows 10 64bit Education 1607

Logs

Web server error log

{"reqId":"7JOt4iqW9S4LarwQuhb4","remoteAddr":"","app":"user_ldap","message":"User userida_5590 is not marked as deleted, not cleaning up.","level":1,"time":"2018-01-17T12:36:06+01:00","method":"--","url":"--","user":"--"}
{"reqId":"\/V1AzzrNp3wSf1RJIjq2","remoteAddr":"","app":"user_ldap","message":"User useridb_7998 is not marked as deleted, not cleaning up.","level":1,"time":"2018-01-17T12:36:09+01:00","method":"--","url":"--","user":"--"}

ownCloud log (data/owncloud.log)

Almost every line has a username, LDAP details or IP...

Browser log

Not relevant.

The text was updated successfully, but these errors were encountered:

ownclouders · 2018-01-17T12:02:44Z

GitMate.io thinks the contributor most likely able to help you is @PVince81.

Possibly related issues are #29856 (Upgrade 9.1.6 to 9.1.7 fails), #26677 (occ upgrade fails with Sabre\VObject\Recur\NoInstancesException), #17061 (Semicolon not supported in commands), #28112 (Not all users are populated in the user list when 'everyone' is selected.), and #7052 (Active directory primary group membership not honored).

PVince81 · 2018-01-17T12:46:18Z

@owncloud/ldap

jvillafanez · 2018-01-17T15:29:19Z

You can try to use the occ ldap:check-user command to recheck if those users are still valid. If so, those users should disappear from the ldap:show-remnants afterwards.

manderson-it · 2018-01-17T18:31:05Z

@jvillafanez Thanks for the idea!
Unfortunately it does not help. I tried that with all of the moved users. Same result, also with --force.
Note: userid is a placeholder, i entered their correct userids as shown by show-remnants. :-)

sudo -u www-data php occ ldap:check-user userid
The user does not exists on LDAP anymore.
Clean up the user's remnants by: ./occ user:delete "userid"

Same result with --force switch.

sudo -u www-data php occ ldap:check-user --force userid
The user does not exists on LDAP anymore.
Clean up the user's remnants by: ./occ user:delete "userid"

manderson-it · 2018-01-17T19:05:15Z

When i login to the webinterface as admin and go to the "manage user" page the moved users are displayed at their new location as userid_1234 instead of just userid.
This corresponds to the entries in database table oc_ldap_user_mapping.
One example of this:

\u owncloud
select * from oc_ldap_user_mapping where owncloud_name like 'userid%';
uid=userid,ou=et,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com     | userid      | 25a78d36-52fa-1031-9621-31dd773e1026
uid=userid,ou=theory,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com | userid_7998 | 4d1dec6e-5aa1-1034-8aff-cf7408922b36

jvillafanez · 2018-01-18T08:44:57Z

I wonder if this has something to do with the usernames not being unique... I did a quick test with the default configuration and I didn't notice anything strange.

When i login to the webinterface as admin and go to the "manage user" page the moved users are displayed at their new location as userid_1234 instead of just userid.

This happens because the username (in your case, the uid) must be unique, so when we try to insert it to the DB we add a random number to prevent a collision with the other one.

The other problem is that we can't detect movements in the LDAP server. What we see is an added user entry and a removed user entry. I'm not sure what we do with the removed entry in 9.1.7 but the added entry might kick in first, which will likely cause a collision with the previous information we have from it.

To keep debugging this, in the oc_ldap_user_mapping table, check if there are rows with the same directory uuid. There shouldn't be duplicates.

manderson-it · 2018-01-18T09:24:27Z

To keep debugging this, in the oc_ldap_user_mapping table, check if there are rows with the same directory uuid. There shouldn't be duplicates.

@jvillafanez Thanks for your time. I checked for uniqueness of all the directory_uuid in the table. To do this I dumped all directory_uuid entries to a file and did the following:

wc -l directory_uuid
431
uniq directory_uuid | wc -l
431

So every entry is unique.

Out-of-the-blue ideas:

move the OpenLDAP user back to the original location, although the double entries will probably not disappear from the database. Maybe i could use occ ldap:check-user then, though?
(probably a bad idea) delete the old database entry from oc_ldap_user_mapping and rename the "_1234" entry to its correct name conforming with OpenLDAP.

jvillafanez · 2018-01-18T11:36:53Z

You can also check the oc_preferences tables, filtering by the target userid. The target user should have an entry like:

| ownclouduserid | user_ldap      | isDeleted                | 0           |

That is what is preventing the deletion.

Ideally, using the ldap:check-user command should flip that value if the user doesn't exists unless there is some error.

Just to make sure, could you show the output of the ldap:check-user and user:delete commands for the target user? In both cases you should use the value of the "owncloud name" in the remnants table.

The expected output should be something like:

root@7e05630544f4:/opt/owncloud# sudo -u www-data ./occ ldap:show-remnants
+--------------------------------------+------------------+------------------+-----------------------------------------------------------------+------------------+-----+--------+
| ownCloud name                        | Display Name     | LDAP UID         | LDAP DN                                                         | Last Login       | Dir | Sharer |
+--------------------------------------+------------------+------------------+-----------------------------------------------------------------+------------------+-----+--------+
| 9c7ff0a2-d008-1036-855b-dd0c704ad877 | aaliyah adams II | aaliyah_adams_II | uid=aaliyah_adams_ii,ou=aaliyahs,ou=people,dc=owncloudqa,dc=com | January 18, 2018 |     | N      |
+--------------------------------------+------------------+------------------+-----------------------------------------------------------------+------------------+-----+--------+
root@7e05630544f4:/opt/owncloud# sudo -u www-data ./occ ldap:check-user 9c7ff0a2-d008-1036-855b-dd0c704ad877
The user does not exists on LDAP anymore.
Clean up the user's remnants by: ./occ user:delete "9c7ff0a2-d008-1036-855b-dd0c704ad877"
root@7e05630544f4:/opt/owncloud# sudo -u www-data ./occ user:delete 9c7ff0a2-d008-1036-855b-dd0c704ad877
The specified user was deleted

manderson-it · 2018-01-18T12:48:31Z

@jvillafanez Hi the information is in previous comments. Here both the check-user followed by the user:delete commands.

sudo -u www-data php occ ldap:check-user userid
The user does not exists on LDAP anymore.
Clean up the user's remnants by: ./occ user:delete "userid"

Same result with --force switch.

sudo -u www-data php occ ldap:check-user --force userid
The user does not exists on LDAP anymore.
Clean up the user's remnants by: ./occ user:delete "userid"

sudo -u www-data php occ user:delete
The specified user could not be deleted. Please check the logs.
/var/log/owncloud.log shows the following messages (Userids are anonymized but are actually displayed in the log with the underscore followed by a number.

{"reqId":"7JOt4iqW9S4LarwQuhb4","remoteAddr":"","app":"user_ldap","message":"User userida_5590 is not marked as deleted, not cleaning up.","level":1,"time":"2018-01-17T12:36:06+01:00","method":"--","url":"--","user":"--"}
{"reqId":"\/V1AzzrNp3wSf1RJIjq2","remoteAddr":"","app":"user_ldap","message":"User useridb_7998 is not marked as deleted, not cleaning up.","level":1,"time":"2018-01-17T12:36:09+01:00","method":"--","url":"--","user":"--"}

Searching in oc_preferences indeed shows isDeleted for the userid before moving to another OU.

select * from oc_preferences where userid = 'userid_3622';
+---------------+----------------+--------------------+---------------------------------+
| userid        | appid          | configkey          | configvalue                     |
+---------------+----------------+--------------------+---------------------------------+
| userid_3622   | files_external | config_version     | 0.5.0                           |
| userid_3622   | settings       | email              | userid@SENSITIVE.SENSITIVE.com     |
| userid_3622   | user_ldap      | displayName        | F. Lastname                      |
| userid_3622   | user_ldap      | homePath           | /var/www/owncloud/data/userid |
| userid_3622   | user_ldap      | lastFeatureRefresh | 1516271378                      |
| userid_3622   | user_ldap      | uid                | userid                        |
+---------------+----------------+--------------------+---------------------------------+
6 rows in set (0.00 sec)

mysql> select * from oc_preferences where userid = 'userid';
+----------+----------------+--------------------+---------------------------------+
| userid   | appid          | configkey          | configvalue                     |
+----------+----------------+--------------------+---------------------------------+
| userid   | files_external | config_version     | 0.5.0                           |
| userid   | settings       | email              | userid@SENSITIVE.SENSITIVE.com     |
| userid   | user_ldap      | displayName        | F. Lasntname                   |
| userid   | user_ldap      | homePath           | /var/www/owncloud/data/userid |
| userid   | user_ldap      | isDeleted          | 1                               |
| userid   | user_ldap      | lastFeatureRefresh | 1484906631                      |
| userid   | user_ldap      | uid                | userid                        |
+----------+----------------+--------------------+---------------------------------+

jvillafanez · 2018-01-19T13:25:04Z

I think what's happening is the following:

ldap:check-user userid should fetch some data from the mappings using the the uid passed as parameter. In our case, it should fetch the uid=userid,ou=et,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com | userid entry, and check if the dn exists in LDAP, which isn't the case.
the user:delete userid, on the contrary, checks against the LDAP directly. This fetches data from the LDAP, which returns the dn of the new entry. Then checks the mapping to get the owncloud uid (I guess userid_7998 in you case) and verify if the user can be deleted with the "isDeleted" flag (which I guess it can't)

Could you verify if what I've said is correct?

Is this a production instance? I'd rather not suggest risky things such a manually fiddling the DB if this is the case.

manderson-it · 2018-01-23T12:55:05Z

@jvillafanez Sorry that it took me so long to reply. Yes it is a production instance.

ldap:check-user userid should fetch some data from the mappings using the the uid passed as parameter. In our case, it should fetch the uid=userid,ou=et,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com | userid entry, and check if the dn exists in LDAP, which isn't the case.
the user:delete userid, on the contrary, checks against the LDAP directly. This fetches data from the LDAP, which returns the dn of the new entry. Then checks the mapping to get the owncloud uid (I guess userid_7998 in you case) and verify if the user can be deleted with the "isDeleted" flag (which I guess it can't)

I think you are correct. Here are two examples. I anonymized with more readable names pparker (Peter Parker) and ldavinci (Leonardo Davinci).

mysql> select * from oc_preferences where userid like '%pparker%';
+---------------+----------------+--------------------+---------------------------------+
| userid        | appid          | configkey          | configvalue                     |
+---------------+----------------+--------------------+---------------------------------+
| pparker       | files_external | config_version     | 0.5.0                           |
| pparker       | settings       | email              | pparker@SENSITIVE.com           |
| pparker       | user_ldap      | displayName        | P. Parker                       |
| pparker       | user_ldap      | homePath           | /var/www/owncloud/data/pparker  |
| pparker       | user_ldap      | isDeleted          | 1                               |
| pparker       | user_ldap      | lastFeatureRefresh | 1484906631                      |
| pparker       | user_ldap      | uid                | pparker                         |
| pparker_3622  | files_external | config_version     | 0.5.0                           |
| pparker_3622  | settings       | email              | pparker@SENSITIVE.com           |
| pparker_3622  | user_ldap      | displayName        | P. Parker                       |
| pparker_3622  | user_ldap      | homePath           | /var/www/owncloud/data/pparker  |
| pparker_3622  | user_ldap      | lastFeatureRefresh | 1516703082                      |
| pparker_3622  | user_ldap      | uid                | pparker                         |
+---------------+----------------+--------------------+---------------------------------+

mysql> select ldap_dn,owncloud_name from oc_ldap_user_mapping where owncloud_name like '%pparker%';
+-------------------------------------------------------------------+---------------+
| ldap_dn                                                           | owncloud_name |
+-------------------------------------------------------------------+---------------+
| uid=pparker,ou=hap,ou=et,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com    | pparker      |
| uid=pparker,ou=pd,ou=plasma,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com | pparker_3622 |
+-------------------------------------------------------------------+---------------+




mysql> select * from oc_preferences where userid like '%ldavinci%';
+---------------+----------------+--------------------+---------------------------------+
| userid        | appid          | configkey          | configvalue                     |
+---------------+----------------+--------------------+---------------------------------+
| ldavinci      | user_ldap      | isDeleted          | 1                               |
| ldavinci_7998 | files_external | config_version     | 0.5.0                           |
| ldavinci_7998 | settings       | email              | ldavinci@SENSITIVE.com          |
| ldavinci_7998 | user_ldap      | displayName        | Leonardo Davinci                |
| ldavinci_7998 | user_ldap      | homePath           | /var/www/owncloud/data/ldavinci |
| ldavinci_7998 | user_ldap      | lastFeatureRefresh | 1516703080                      |
| ldavinci_7998 | user_ldap      | uid                | ldavinci                        |
+---------------+----------------+--------------------+---------------------------------+

mysql> select ldap_dn,owncloud_name from oc_ldap_user_mapping where owncloud_name like '%ldavinci%';
+--------------------------------------------------------------+---------------+
| ldap_dn                                                      | owncloud_name |
+--------------------------------------------------------------+---------------+
| uid=ldavinci,ou=et,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com      | ldavinci      |
| uid=ldavinci,ou=theorie,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com | ldavinci_7998 |
+--------------------------------------------------------------+---------------+

jvillafanez · 2018-01-23T17:57:23Z

Any chance to update to 10.0.5?

Being a production instance I'd rather not to touch anything manually, and I still need to reproduce the problem. The soonest would be with 9.1.8.

For 10.0.x the behaviour has changed, so at least for LDAP, the user:delete will delete the account data although the user can still be retrieved from LDAP. I'm not sure how it will behave in your environment so make a backup of everything in order to rollback if something goes wrong.

jvillafanez · 2018-01-24T09:46:46Z

Checked from a clean 10.0.5 instance, the movement works fairly well.

The moved accounts will be detected as non-existent, so you'll have the option to disable or remove the accounts. Since you've moved the accounts, you should disable the accounts and manually reenable them afterwards.
Removing the account would imply removing the ownCloud data associated to the account, even though the user will receive another account (as long as the LDAP user is still within the reachable limits of the LDAP app)

As said, this is from a clean 10.0.5 instance. The update from 9.1.7 with your scenario is yet to be tested.

jvillafanez · 2018-01-24T11:59:27Z

I think what happened is that you didn't move the entries but copied and delete them, or at least the process seems to be that way. At some point ownCloud has detected both LDAP entries as valid, otherwise I can't reproduce the problem even in 9.1.7.

Upgrading to 10.0.5 won't solved the problem because only one of those entry will generate a valid account (the existing entry). This means that the other entry will remain unaccesible because it doesn't have a valid account.
The target user (ldavinci in your case) will be detected as missing by the LDAP, but since ownCloud doesn't has a valid account for it you won't be able to delete it.

Whether intentionally or accidentally, this is a case of uid duplication, which is something admins must avoid. This is why we're recommending not to use the LDAP uid and use the default objectguid (the ugly alphanumeric characters)

| uid=abagail_windler_ii,ou=abagails,ou=people,dc=owncloudqa,dc=com     | abagail_windler_II     | 9daf1976-d008-1036-893e-dd0c704ad877 |
| uid=abagail_wisoky,ou=moved,ou=people,dc=owncloudqa,dc=com            | abagail_wisoky         | 9daf3c1c-d008-1036-893f-dd0c704ad877 |
| uid=abagail_wisoky,ou=abagails,ou=people,dc=owncloudqa,dc=com         | abagail_wisoky_8787    | 577e1aac-953c-1037-9ba9-c90243948042 |
| uid=abagail_witting,ou=moved,ou=people,dc=owncloudqa,dc=com           | abagail_witting        | 9daf7b32-d008-1036-8940-dd0c704ad877 |

Note that the objectguid is different for both entries in my case.

As said, upgrading to 10.0.5 won't solve the problem, but it should mitigate the problem because you'll sync the user data on demand, which means that you won't sync data until all the changes are applied to the LDAP server. Obviously, same restrictions apply in any case, in particular, the uniqueness of the username.

So far, I'm not aware of anything that can repair that state.

cdamken · 2018-02-01T22:29:56Z

I'm not sure if this will help, but I will explain what I understand:

once you moved the user to another ou:

uid=userid,ou=et,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com | userid | 25a78d36-52fa-1031-9621-31dd773e1026
uid=userid,ou=theory,ou=users,dc=SENSITIVE,dc=SENSITIVE,dc=com | userid_7998 | 4d1dec6e-5aa1-1034-8aff-cf7408922b36

you change the UUID, that is by default your key in:

| user_ldap | ldap_expert_uuid_user_attr | |

Because you have different UUIDs then your configuration tries to add ad new uid:

| user_ldap | ldap_expert_username_attr | uid |

Because you have the UID already used it will create a random _1234 Number to avoid conflicts.

I don't know if you can change back the users userid_7998 to userid`

But you can get rid of the user that you don't want to have with this process:

!!!Be careful using this = Make a backup first!:

make select for each user you have duplicated:

SELECT FROM oc_preferences WHERE userid='XXXX';
SELECT FROM oc_ldap_user_mapping WHERE owncloud_name='XXXX';
SELECT FROM oc_group_user WHERE uid='XXXX';
SELECT FROM oc_mounts WHERE user_id='XXXX';
SELECT FROM oc_preferences WHERE configkey='uid' AND configvalue='XXXX';

If you are sure this is the user you want to delete:

DELETE FROM oc_preferences WHERE userid='XXXX';
DELETE FROM oc_ldap_user_mapping WHERE owncloud_name='XXXX';
DELETE FROM oc_group_user WHERE uid='XXXX';
DELETE FROM oc_mounts WHERE user_id='XXXX';
DELETE FROM oc_preferences WHERE configkey='uid' AND configvalue='XXXX';

This should clear the most relevant parts, and you should also check if a home storage exists for that user:

SELECT * FROM oc_storages WHERE id='home::XXXX';

if so delete it and also all filecache entries that belong to it:

DELETE FROM oc_filecache WHERE storage=?;
DELETE FROM oc_storages WHERE numeric_id=?;

I don't know if overwriting the uid could help to have it the normal one.

@jvillafanez You are the expert here.

What I also recommend is to upgrade to oC10 (at least 10.0.4) and use the user_ldap app 0.10.0 (or if it's any newer version)

jvillafanez · 2018-02-02T09:54:42Z

Let me be a bit strict here:

The fact that those entries have different UUID means that the entry didn't move, it was copied (and maybe the old one was deleted after). In any case, both entries were detected by ownCloud at some point, so as far a ownCloud concerns, those are 2 different users.
Modifying the DB manually is untested, unsupported and with unknown consecuences. Basically, use it at your own risk.
ownCloud should provide tools to deal with this scenario. Right now it doesn't.

cdamken · 2018-02-05T14:13:55Z

Yes, you are right, the UUIDs are different in the example that is above, what I suspect is that the old user was deleted and a new with the same cn was created that explains the change from the UUID.

if the UUID would be the same, I think that @tomneedham already made some improvements in 0.10.0 and oC10.0.4 where the users are detected as the same and no other new user is created.

I agree with you too, modifying the DB is risky and that's why I recommend a full back-up before.

I also know that in some behaviors is complicated to remove the user:
#26357

I also know that it helps to fix some issue:
https://github.com/owncloud/enterprise/issues/1880

I agree that we have to build something to force removing users that we are sure that have to be removed.

stale · 2021-09-20T23:35:13Z

This issue has been automatically closed.

ownclouders added Type:Bug security server app:user_ldap labels Jan 17, 2018

ownclouders added the status/STALE label Mar 8, 2018

micbar removed the app:user_ldap label Jan 18, 2021

stale bot closed this as completed Sep 20, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

9.1.7 occ user:delete fails with moved users #30170

9.1.7 occ user:delete fails with moved users #30170

manderson-it commented Jan 17, 2018

ownclouders commented Jan 17, 2018

PVince81 commented Jan 17, 2018

jvillafanez commented Jan 17, 2018

manderson-it commented Jan 17, 2018 •

edited

manderson-it commented Jan 17, 2018

jvillafanez commented Jan 18, 2018

manderson-it commented Jan 18, 2018

jvillafanez commented Jan 18, 2018

manderson-it commented Jan 18, 2018

jvillafanez commented Jan 19, 2018

manderson-it commented Jan 23, 2018

jvillafanez commented Jan 23, 2018

jvillafanez commented Jan 24, 2018

jvillafanez commented Jan 24, 2018

cdamken commented Feb 1, 2018 •

edited

jvillafanez commented Feb 2, 2018

cdamken commented Feb 5, 2018

stale bot commented Sep 20, 2021

9.1.7 occ user:delete fails with moved users #30170

9.1.7 occ user:delete fails with moved users #30170

Comments

manderson-it commented Jan 17, 2018

Steps to reproduce

Expected behaviour

Actual behaviour

Server configuration

LDAP configuration (delete this part if not used)

Client configuration

Logs

Web server error log

ownCloud log (data/owncloud.log)

Browser log

ownclouders commented Jan 17, 2018

PVince81 commented Jan 17, 2018

jvillafanez commented Jan 17, 2018

manderson-it commented Jan 17, 2018 • edited

manderson-it commented Jan 17, 2018

jvillafanez commented Jan 18, 2018

manderson-it commented Jan 18, 2018

jvillafanez commented Jan 18, 2018

manderson-it commented Jan 18, 2018

jvillafanez commented Jan 19, 2018

manderson-it commented Jan 23, 2018

jvillafanez commented Jan 23, 2018

jvillafanez commented Jan 24, 2018

jvillafanez commented Jan 24, 2018

cdamken commented Feb 1, 2018 • edited

jvillafanez commented Feb 2, 2018

cdamken commented Feb 5, 2018

stale bot commented Sep 20, 2021

manderson-it commented Jan 17, 2018 •

edited

cdamken commented Feb 1, 2018 •

edited