After upgrdae from 5.0.4 to 6.2.5 - no login possible

running Ubuntu 14.04.5 LTS with mysql

after following the upgrade instructions the server started. When trying to login over the webinterface an error message appears:
Page unavailable
Sorry, but the requested page is unavailable due to a server hiccup.
Our engineers have been notified, so check back later.
(http://192.168.178.xxx:8000/accounts/login/?next=/)

Seafile client 4.3.3 says trying to login “internal servererror”

I cleared the server cache in /tmp/seahub_cache

seahub.log is only showing old entries from 2017

last seafile log entries are:

[08/12/18 13:59:38] http-server.c(161): fileserver: worker_threads = 10 [08/12/18 13:59:38] http-server.c(176): fileserver: fixed_block_size = 8388608 [08/12/18 13:59:38] http-server.c(191): fileserver: web_token_expire_time = 3600 [08/12/18 13:59:38] http-server.c(206): fileserver: max_indexing_threads = 1 [08/12/2018 01:59:38 PM] ../common/mq-mgr.c(54): [mq client] mq cilent is started [08/12/2018 01:59:39 PM] size-sched.c(96): Repo size compute queue size is 0 [08/12/2018 02:04:17 PM] Disconnected from daemon [08/12/18 14:04:59] http-server.c(161): fileserver: worker_threads = 10 [08/12/18 14:04:59] http-server.c(176): fileserver: fixed_block_size = 8388608 [08/12/18 14:04:59] http-server.c(191): fileserver: web_token_expire_time = 3600 [08/12/18 14:04:59] http-server.c(206): fileserver: max_indexing_threads = 1 [08/12/2018 02:05:00 PM] ../common/mq-mgr.c(54): [mq client] mq cilent is started [08/12/2018 02:05:01 PM] size-sched.c(96): Repo size compute queue size is 0 [08/12/2018 02:10:01 PM] size-sched.c(96): Repo size compute queue size is 0 [08/12/2018 02:15:01 PM] size-sched.c(96): Repo size compute queue size is 0 [08/12/2018 02:20:01 PM] size-sched.c(96): Repo size compute queue size is 0

maybe one can find hints in seahub_django_request.log:

2018-08-12 12:17:02,792 [ERROR] django.request:256 handle_uncaught_exception Internal Server Error: /accounts/login/ Traceback (most recent call last): File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/core/handlers/base.py", line 132, in get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/utils/decorators.py", line 110, in _wrapped_view response = view_func(request, *args, **kwargs) File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/views/decorators/cache.py", line 57, in _wrapped_view_func response = view_func(request, *args, **kwargs) File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/auth/views.py", line 113, in login if form.is_valid(): File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/forms/forms.py", line 184, in is_valid return self.is_bound and not self.errors File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/forms/forms.py", line 176, in errors self.full_clean() File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/forms/forms.py", line 393, in full_clean self._clean_form() File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/forms/forms.py", line 417, in _clean_form cleaned_data = self.clean() File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/auth/forms.py", line 66, in clean username = self.get_username_by_login(login) File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/auth/forms.py", line 46, in get_username_by_login username = Profile.objects.get_username_by_login_id(login) File "/opt/seafile/seafile-server-6.2.5/seahub/seahub/profile/models.py", line 93, in get_username_by_login_id return super(ProfileManager, self).get(login_id=login_id).user File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/manager.py", line 127, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/query.py", line 328, in get num = len(clone) File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/query.py", line 144, in __len__ self._fetch_all() File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/query.py", line 965, in _fetch_all self._result_cache = list(self.iterator()) File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/query.py", line 238, in iterator results = compiler.execute_sql() File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/models/sql/compiler.py", line 840, in execute_sql cursor.execute(sql, params) File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/backends/utils.py", line 64, in execute return self.cursor.execute(sql, params) File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/utils.py", line 98, in __exit__ six.reraise(dj_exc_type, dj_exc_value, traceback) File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/backends/utils.py", line 64, in execute return self.cursor.execute(sql, params) File "/opt/seafile/seafile-server-6.2.5/seahub/thirdpart/Django-1.8.18-py2.7.egg/django/db/backends/mysql/base.py", line 124, in execute return self.cursor.execute(query, args) File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in execute self.errorhandler(self, exc, value) File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler raise errorclass, errorvalue OperationalError: (1054, "Unknown column 'profile_profile.list_in_address_book' in 'field list'")

can anyone help please?

Greetings, Jinx.

No hints? Anyone plz?

wrong permissions? Checked the webserver log?

stuff seems missing in the DB. Did you run all the upgrade scripts?

yeah. today I did a fresh install of the server, trying to use the old mysql (ccnet-db, seafile-db, seahub-db) databases. avoiding the existing api2token problem, I managed to dump the old db’s (via mysqldump) for reimporting (which was hard enough, considering the fact that hyphens are being used in the names of the databases… why would one do that?). done that, the freaking problem described in my first post persisted. something must have been wrong with the databases, of course I don’t know what exactly.

Finally I exported all the files, dropped the old 3 databases in mysql, set up new ones (“ccnet_db”!) and now I’m resynchronizing everything, taking hours. frustrating.

the topic may be closed w/out solution.