6.2.5 to 6.3.1 upgrade failed

I tried to upgrade from 6.2.5 to 6.3.1 (using Mysql 5.7.22 on Ubuntu 16.04) and executed upgrade_6.2_6.3.sh

The database upgrade failed in ccnet.sql because it could not execute

ALTER TABLE OrgUser DROP primary key;
ALTER TABLE OrgGroup DROP primary key;

These tables did not have primary keys.

Not sure whether this is a bug from previous upgrades where the tables should have gained primary keys or whether this upgrade script is bad. Just wanted to let you know.

I could fix it by removing the DROP primary key statements.

I also got

[INFO] You are using MySQL
[INFO] updating seahub database…
/srv/seafile/informatik/seafile-server-6.3.1/upgrade/db_update_helper.py:348: Warning: Changing sql mode ‘NO_AUTO_CREATE_USER’ is deprecated. It will be removed in a future release.

What went wrong ?

1 Like

I not a specialist for mysql, but version 5 is much too old and not supported. You should use you backups of the databases and import them into the new mariadb server. Probably it will work then.

Same Issue her. Same OS, Same mysql Version.

MySQL 5.7 isn’t old and is supported by seafile: https://en.wikipedia.org/wiki/MySQL#Release_history

On my Ubuntu 16.04 with MySQL 5.7.22, the update passed without any errors.

best regards,


Mysql and maria db versioning works differently. Doesn’t really say anything about its age.

1 Like

The table wiki_wiki was created. My bad, it was on a second page while looking it up with phpmyadmin.

So the only real problem was that the ccnet.sql could not be executed because the primary keys could not be dropped as they did not exist…

This two tables do have primary keys before upgrade. It should be somehow your installation missed the primary keys before.

When were they added ?
I upgraded my seafile from maybe 2.x.y to 6.3.1 during the last years so I must have missed the addition of those specific primary keys somewhere. If I can find that step I can check wether other table updates are also missing.

Since another user has reported the same error it could be worthwhile to investigate.


OrgUser has not been modified by any upgrade script. Maybe the create statement was changed in the code with some release?

So it looks like it would be the best to adjust the statement to only drop the pk if it exists.

1 Like

This does sound likely as some users encounter the problem and some don’t. Create statement must have changed over time and old users won’t have the primary keys.


We’ll improve the robustness of the upgrade script. SQL errors will be skipped and continue execution of the remaining upgrade SQL queries. The SQL errors can be fixed manually after most queries are done.