Migration from 11 to 12 with LDAP user database

Seafile Server
1

I have a binary setup of Seafile 11 that has been working normally and well for a long time. The users are retrieved from an LDAP server. Since the LDAP migration in version 11, every LDAP user is also listed under Database. The same applies to lower LDAP. But the list under LDAP (Import) is empty.

I converted this to a Docker deployment, which also works without problems. There is one difference, however: in the binary setup, the social_auth_usersocialauth table is empty; in the Docker setup, after an LDAP user logs in, a record is written to this table if it doesn’t already exist. The username and uid columns are identical; they are the user’s email address.

In the system administration, I no longer see the LDAP user I logged in with under Users, LDAP, but I can see it under LDAP (Import). Groups and libraries are identical to the binary setup.

After upgrading the Docker setup to version 12, I can still log in with the LDAP user, but Seafile no longer recognizes it as the same user and creates a new library called “My Library.” When I look in the social_auth_usersocialauth table, the previous user has been deleted and a new one has been created with the value edfc631e24ca4d568d77f7b3b9351e7f@auth.local in the username column. This column contains the previous email address.

In the system administration, under Users, Database, I only see the two users who have already logged in. The LDAP user I logged in with is missing under LDAP, but it is listed under LDAP (Import). And the user with @auth.local is listed under LDAP.

What kind of mechanism is this?

I use a local user for system administration. When I log in with this user and try to access the “My Library” library, I get the error: The sharing permissions for the library were not found.

When I switch to the system administration, I can see that far fewer libraries are displayed than before. There are no longer any groups. The LDAP user I previously logged in with is no longer listed under Users.

What I noticed: When I first start the container with version 12, this error message appears three times:
seafile-mysql | 2025-10-24 14:54:42 6 [Warning] Aborted connection 6 to db: ‘seafile_db’ user: ‘seafile’ host: ‘172.18.0.4’ (Got an error reading communication packets)
seafile-mysql | 2025-10-24 14:54:42 7 [Warning] Aborted connection 7 to db: ‘seahub_db’ user: ‘seafile’ host: ‘172.18.0.4’ (Got an error reading communication packets)
seafile-mysql | 2025-10-24 14:54:45 8 [Warning] Aborted connection 8 to db: ‘seahub_db’ user: ‘seafile’ host: ‘172.18.0.4’ (Got an error reading communication packets)

However, database access works after this.

I can’t offer this to my customer. Do I have to stay on version 11?

2

A few questions:

  1. Have you run the migrate_ldapusers.py script after upgrade to version 11?
  2. How many users in your server?
  3. Can you list the complete contents of ccnet.EmailUsers and social_auth_usersocialauth?
  4. How is your LDAP configured, can you paste your related part in seahub_settings.py?
3
  1. Yes, I did that.
  2. There are 27 users logging in via the LDAP user base.
  3. Yes, I can list these tables. Do you need this data? I first need to get permission from the customer to share it.
  4. Here my LDAP configuration:
# Configuration items for LDAP login
ENABLE_LDAP = True
LDAP_SERVER_URL = 'ldaps://ldap.domain.tld'
LDAP_BASE_DN = 'ou=users,dc=domain,dc=tld'
LDAP_ADMIN_DN = 'cn=username,dc=domain,dc=tld'
LDAP_ADMIN_PASSWORD = 'very strong password'
LDAP_PROVIDER = 'ldap'
LDAP_LOGIN_ATTR = 'mail'

# For update user info when login
LDAP_CONTACT_EMAIL_ATTR = ''
LDAP_USER_ROLE_ATTR = ''
LDAP_USER_FIRST_NAME_ATTR = 'givenName'
LDAP_USER_LAST_NAME_ATTR = 'sn'
LDAP_USER_NAME_REVERSE = False

I also upgraded the binary setup. It’s working as expected. Everything is there: the libraries, groups, and users. When you log in as LDAP user, all the libraries and files are there.

But I don’t want a setup like that anymore; besides, the Notification Server and Seadoc require Docker anyway.

I also imported a database backup of all three Seafile 12 databases from the binary setup into the Docker Seafile 12 setup. But that doesn’t help either. The same symptoms occur this way as described at the beginning. I don’t understand that.

4

If you have 27 users in LDAP user base, but your ccnet_db.EmailUsers only have 2 users, it is likely you have errors in migrating the database from non-docker based installation to docker based installation.

You should check ccnet_db.EmailUsers and social_auth_usersocialauth in your old server and new server and make sure they are identical.

5

How Seafile LDAP work

When a user logs in via LDAP in Seafile, the system first searches for the user using the string entered in the username/email field of the login dialog, referred to as the login_string.

The login_string is utilized to locate an existing user by matching it against the contact_email, login_id field, or email field in the ccnet_db.EmailUser. If a matching user is found, we retrieve the user ID associated with that user. This user ID is then used to search the social_auth_usersocialauth table to find the user’s login attribute in LDAP (commonly referred to as the user ID in LDAP).

If no matching user is found, the login_string is used as the login attribute in LDAP (the user ID in LDAP).

Next, we search LDAP for the user using the user ID in LDAP.

If such a user is found in LDAP and the password matches, and if there is no previous record in social_auth_usersocialauth, a new entry will be created in social_auth_usersocialauth to link the user ID in LDAP to the user ID in Seafile, and the user’s information will be updated accordingly.

About the UI in the admin panel

“LDAP（imported)” page displays all imported users in LDAP using records in social_auth_usersocialauth.

“LDAP” page displays all users in the original LDAP server.

How to troubleshooting is your case

You can check your database records to reason about which step goes wrong.

6

If you have 27 users in LDAP user base, but your ccnet_db.EmailUsers only have 2 users, it is likely you have errors in migrating the database from non-docker based installation to docker based installation.

You should check ccnet_db.EmailUsers and social_auth_usersocialauth in your old server and new server and make sure they are identical.

I only see two users under version 12. In the “original” version (binary setup with version 11), I see 28 users, one of which is not an LDAP user. The ccnet_db.LDAPUsers table, which is apparently no longer needed, contains 27 records. So, all 27 were copied to the ccnet_db.EmailUser table.

However, the seahub_db.social_auth_usersocialauth table is empty, which I don’t understand. The system is running perfectly. But I was already surprised when migrating from version 10 to 11 that the LPAP (Import) column is now empty. The system should automatically populate the seahub_db.social_auth_usersocialauth table, but it doesn’t.

Only after I migrate this environment to a Docker setup with Seafile 11 does this table populate every time someone logs in. Strangely, version 12 doesn’t care at all; it deletes the existing entries in the social_auth_usersocialauth table and adds new ones.

What’s about with the seahub_db.profile_profile table?

7

There is no contact_email and login_id field in ccnet_db.EmailUser, only email.

8

As I mentioned before, this is a very old installation. Back then, I chose the -db as suffix for the databases, not _db. So, a hyphen instead of an underline.

I also use multiple databases in a test environment, so in this case, the databases are called simply ccnet, seafile, and seahub. So, without the _db suffix.

These database names are correctly configured in the ccnet.conf, seafile.conf, seafevents.conf, and seahub_settings.py files, so I assumed Seafile would evaluate this information and work with the correct databases. This seems to work when running the Seafile container in version 11, but probably not the first time the Seafile container is used in version 12.

I’ve now added the following three variables in the file .env:
SEAFILE_MYSQL_DB_CCNET_DB_NAME=ccnet
SEAFILE_MYSQL_DB_SEAFILE_DB_NAME=seafile
SEAFILE_MYSQL_DB_SEAHUB_DB_NAME=seahub

And now I can work with the Seafile container version 12 the way I thought it should. I can log in with the existing users, and everything is there.

I’d still like to know why the social_auth_usersocialauth able isn’t populated automatically in the previous binary setup. Should I do it manually?

9

social_auth_usersocialauth is designed to be populated when a user login. You can add entries in it manually to link LDAP user to Seafile user.

10

Glad to see the problem is solved. I was thinking that you were using a wrong database.

11

So I wouldn’t say I’m using the wrong databases, just different ones. It’s more likely that Seafile is accessing its internally predefined databases instead of the ones specified in the configuration files.

But I can’t really judge that, even though I could theoretically look at the code.

Thanks for your help.