LDAP users lost


#1

Steps to reproduce

Expected behaviour

Tell us what should happen

Actual behaviour

LDAP sync gets lost. All employees get a message “all files from the sync folder got deleted. Do you want to keep or delete all files?” on the owncloud client.
All users get a new USER ID with a suffix (as seen in phpmyadmin) and therefore a new folder on the server.
This happened the SECOND time today since I’ve updated to 10.0.10

Server configuration

Operating system: Debian 3.16.39-1+deb8u2

Web server: Apache/2.4.10

Database: Ver 8.42 Distrib 5.5.54,

PHP version: PHP 5.6.38-0+deb8u1

ownCloud version: (see ownCloud admin page)

Updated from an older ownCloud or fresh install:

Where did you install ownCloud from:

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder



    "system": {
        "instanceid": "51e4e89fdffd9",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "REMOVED SENSITIVE VALUE",
            "192.168.0.31"
        ],
        "datadirectory": "\/owncloud\/data",
        "overwrite.cli.url": "hREMOVED SENSITIVE VALUE",
        "dbtype": "mysql",
        "version": "10.0.10.4",
        "dbname": "owncloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "logtimezone": "UTC",
        "installed": true,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "forcessl": true,
        "ldapIgnoreNamingRules": false,
        "theme": "",
        "loglevel": 3,
        "maintenance": false,
        "trashbin_retention_obligation": "auto"

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.
Enabled:
  - activity: 2.3.8
  - comments: 0.3.0
  - configreport: 0.1.1
  - dav: 0.4.0
  - federatedfilesharing: 0.3.1
  - federation: 0.1.0
  - files: 1.5.1
  - files_external: 0.7.1
  - files_pdfviewer: 0.9.0
  - files_sharing: 0.11.0
  - files_texteditor: 2.2.1
  - files_videoplayer: 0.9.8
  - market: 0.2.5
  - notifications: 0.3.5
  - provisioning_api: 0.5.0
  - systemtags: 0.3.0
  - templateeditor: 0.3.1
  - updatenotification: 0.2.1
  - user_ldap: 0.11.0
Disabled:
  - encryption
  - external
  - files_trashbin
  - files_versions
  - firstrunwizard
  - user_external


**Are you using external storage, if yes which one:** local/smb/sftp/...

**Are you using encryption:** yes/no

**Are you using an external user-backend, if yes which one:** LDAP/ActiveDirectory/Webdav/...

#### LDAP configuration (delete this part if not used)

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your ownCloud installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM oc_appconfig WHERE appid = ‘user_ldap’;

Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.


### Client configuration
**Browser:**

**Operating system:**

### Logs
#### Web server error log

Insert your webserver log here


#### ownCloud log (data/owncloud.log)

Insert your ownCloud log here


#### Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log
c) …


#2

Hey,

if something like this is happening after an update i personally would report such an issue to a bug tracker rather then to a user support forums.

I’m only not sure which one of the below could better fit. :confused:


#3

I would also want to find out how you updated.

You are clearly experiencing an issue now, but we only know what the symptoms are, the cause is still unclear.