Hello,
I just installed Seafile 13-latest with docker on a fresh Ubuntu-24.04 server.
I played around with user registration in order to test it before I reach out to real users.
I created 2 accounts and deleted them later.
Now, when I try to use the same e-Mail address again, an internal server error message is shown.
When I refresh the users page, a new user appeared, but with an id for the name and the same id @auth.local for the email.
No mail is sent to the inserted email address.
Mark, I used a ‘fresh’ e-mail address (Not used before) and everything worked like a charm.
Cleaning Database and garbage collection did not help either.
Do someone know the magic table where I may remove those id’s so I can re-use my e-mail addresses I used before?
Regards Oliver
Found out myself. There is a table profile_profile in the database seahub_db which still had entries for the 2 email addresses I had difficulties with. I deleted those records, then I was able to use those addresses again.
As to why this did not work I can only guess. I know that my smtp settings to send email were wrong when I first tried to register those addresses. And I removed the records from table EmailUser in database ccnet_db, which was probably also not a good idea. But that is what you get proposed when asking the internet…
This behavior is related to the Virtual User ID system introduced in Seafile 11. In Seafile 13, the system uses an internal UUID (the @auth.local address you see) as the primary identifier. Your actual email address is then mapped to this ID in secondary tables.
The “Internal Server Error” occurs because when you delete a user, some entries might persist in the database. When you try to re-register, the system finds the old email entry and triggers a conflict.
To resolve this and “clean” the email address for reuse, you should check the following “magic tables” in your seahub_db:
profile_profile: Look for the old email address in the contact_email column.social_auth_usersocialauth: If you are using any external authentication (or even if not, sometimes entries land here), check the uid column.EmailUser: Verify if there’s a mapping left in the emailuser table that points to the old UUID.
Once you manually remove the rows associated with those specific email addresses from these tables, you should be able to create the user again without the internal server error.
Note: Since version 11, it is normal for users to have an internal ID like [long-uuid]@auth.local. This allows users to change their email addresses without losing their libraries and permissions.
Thank you for clarification. So I found the right tables. I do not use social auth, so this table was empty.