Upgrade to Seafile 13 from 12, startup error

*** Running /etc/my_init.d/01_create_data_links.sh...
*** Booting runit daemon...
*** Runit started as PID 16
*** Running /scripts/enterpoint.sh...
2025-12-09 10:58:40 Waiting Nginx
nginx: [warn] conflicting server name "" on 0.0.0.0:80, ignored
2025-12-09 10:58:41 Nginx ready
2025-12-09 10:58:41 This is an idle script (infinite loop) to keep container running.
nginx: [warn] conflicting server name "" on 0.0.0.0:80, ignored
[2025-12-09 10:58:41] Skip running setup-seafile-mysql.py because there is existing seafile-data folder.
[12/09/2025 10:58:41][upgrade]: The container was recreated, start fix the media symlinks
mv: not replacing '/shared/seafile/seahub-data/avatars/default-non-register.jpg'
mv: not replacing '/shared/seafile/seahub-data/avatars/default.png'
mv: not replacing '/shared/seafile/seahub-data/avatars/groups'
[12/09/2025 10:58:41][upgrade]: Done

Starting seafile server, please wait ...
Seafile server started

Done.

Starting seahub at port 8000 ...
Error:Seahub failed to start.
Please try to run "./seahub.sh start" again
Traceback (most recent call last):
  File "/scripts/start.py", line 91, in <module>
    main()
  File "/scripts/start.py", line 77, in main
    call('{} start'.format(get_script('seahub.sh')))
  File "/scripts/utils.py", line 71, in call
    return subprocess.check_call(*a, **kw)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '/opt/seafile/seafile-pro-server-13.0.14/seahub.sh start' returned non-zero exit status 1.

Any idea?

and in seahub.error.log

2025/12/09 10:58:51 [error] 48#48: *3 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8000/", host: "localhost"
2025/12/09 10:59:21 [error] 47#47: *5 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8000/", host: "localhost"
2025/12/09 10:59:51 [error] 47#47: *7 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8000/", host: "localhost"
2025/12/09 11:00:21 [error] 47#47: *9 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8000/", host: "localhost"
2025/12/09 11:00:51 [error] 47#47: *11 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8000/", host: "localhost"
2025/12/09 11:01:21 [error] 47#47: *13 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8000/", host: "localhost"
1 Like

Somehow, I resolve the issue by revert it back to 12 and then upgrade to 13 again. Some pitfalls found.

  1. My .env password for MySQL is incorrect. In 12, this configuration was primarily taken from seafile or seahub settings file. So I didn’t realize the password is incorrect.
  2. I cleaned up seafile and seahub setting this time to make it work.

In conclusion, the upgrade process may need to check configuration overwriting issues. Although the document says .env file has priority, but it’s not always the case.

I experienced the same issue now, but I confirmed that my password in .env is correct. And I cleaned seafile.conf and seahub as indicated by the manual. any further ideas?
Of note, I wanted to use valkey instead of redis, since I already use the former for immich. Could this be the issue? valkey should be compatible with redis…. But i set it up without a password, so i left redis password empty. should be ok? Thanks, Ruediger

I am scatter head and head similar issues. Eventually I noticed that names of lot environmental variables had changed, I have updated them and voila!. Beware and tripplecheck.

Hello! Thanks for your suggestion, I tried again and it failed again, but now seafile also refuses to start after downgrading to latest v12 as well :frowning: i am in panic mode now….

Can anyone please suggest how to fix this nightmare? I tried before on a virtual machine, fresh install of version 12 and upgrade to v13, this worked without ikssues, but on my production system it kept failing…

Now my entire seafile data is unreadable :frowning:

I Hope someone can help.

Error:Seahub failed to start.
Please try to run “./seahub.sh start” again
Traceback (most recent call last):
File “/scripts/start.py”, line 94, in
main()
File “/scripts/start.py”, line 80, in main
call(‘{} start’.format(get_script(‘seahub.sh’)))
File “/scripts/utils.py”, line 70, in call
return subprocess.check_call(*a, **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.12/subprocess.py”, line 413, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command ‘/opt/seafile/seafile-server-12.0.14/seahub.sh start’ returned non-zero exit status 1.

To debug Seahub startup issues and see error messages directly on the console, you can modify the Gunicorn configuration as follows:

  1. Open the file conf/gunicorn.conf.py in your Seafile installation directory.
  2. Locate the line that says daemon = True.
  3. Change it to daemon = False.
  4. Save the file and run ./seahub.sh start again.

By setting daemon = False, Gunicorn will run in the foreground and print any initialization errors or Python tracebacks directly to your terminal window, which is helpful when Seahub fails so early that it doesn’t write to the standard log files.

More analysis and ways to debug the issue:

Based on the logs and description you provided, the issue where Seahub fails to start (even after downgrading to version 12) is likely caused by incomplete configuration migration or conflicting settings between the new .env file and the old configuration files.

Here is an analysis of the possible causes and steps to resolve the “nightmare”:

1. Incomplete Configuration Cleanup

Starting from version 12.0 and especially in 13.0, Seafile has moved many configurations (Database, Cache) to the .env file located in the conf/ directory. If you manually cleaned seafile.conf and seahub_settings.py but left certain blocks or have conflicting values, Seahub will fail to initialize.

What to check:

  • seahub_settings.py: Ensure the DATABASES and CACHES blocks are completely removed if they are defined in your .env file 1 2.
  • seafile.conf: Ensure the [database] and [memcached] sections are removed 2.
  • ALLOWED_HOSTS: In version 12.0+, if ALLOWED_HOSTS is defined in seahub_settings.py, it must include '127.0.0.1' for internal communication, or be removed entirely to allow the default behavior 3.

2. Cache Provider Issues (Redis/Valkey)

You mentioned using Valkey without a password and leaving the Redis password empty.

  • In the .env file, ensure CACHE_PROVIDER=redis is set.
  • Even if there is no password, ensure the REDIS_HOST and REDIS_PORT are correctly pointing to your Valkey instance.
  • Crucial for v13: Version 13.0 requires the django-redis and redis Python packages. If you are on a binary install, ensure these are installed in your virtual environment 1.

3. Missing Mandatory Variables in .env

Seafile 12 and 13 rely heavily on the .env file. If any of the following are missing or incorrect, the startup script will fail:

  • JWT_PRIVATE_KEY: Must be a random string of at least 32 characters 1 3.
  • SEAFILE_SERVER_HOSTNAME and SEAFILE_SERVER_PROTOCOL: These have replaced SERVICE_URL and FILE_SERVER_ROOT 3.
  • SEAFILE_MYSQL_DB_PASSWORD: Ensure this is present and correct in .env.

4. Why the Downgrade Failed

The reason it “refuses to start after downgrading” is likely because the upgrade script for 13.0 might have already modified the database schema or created a .env file that version 12.0 is now trying to use with incompatible logic (e.g., if you updated environment variable names that version 12 doesn’t recognize or expects in a different format).

Recommended Recovery Steps:

  1. Check Seahub Django Logs: The seahub.error.log you posted shows Nginx connection errors (Connection refused), which is a symptom that Seahub isn’t running. Check /opt/seafile/logs/seahub.log (or the Django log file) for the actual Python traceback. It will likely tell you exactly which configuration key is missing or which database connection failed.
  2. Verify .env Location: Ensure your .env file is inside the conf/ directory of your Seafile installation 1.
  3. Validate Database Credentials: Try connecting to your MySQL/MariaDB manually from the terminal using the credentials in your .env to ensure the password is correct.
  4. Fix ALLOWED_HOSTS: Add ALLOWED_HOSTS = ['your-domain.com', '127.0.0.1'] to seahub_settings.py if it’s missing
1 Like

Thank you so much for your detailed explanation, I was finally able to restart seahub :slight_smile:
However, I noticed two things with daemon=False.
Using memcached, seafile complains WARNING:root:Redis has not been set up.
Using redis, seafile complains about memcached missing, but in both cases seahub works now.
Is this expected behaviour?
I tried this extended debugging mode and the error appears also on a fresh installation of seafile in the VM.

Second thing, seahub complains on the fresh install with daemon=False:

/opt/seafile/seafile-server-13.0.20/seahub/seahub/utils/htmldiff.py:1383: SyntaxWarning: invalid escape sequence ‘+’
change_re = re.compile(‘(++|-+|^+)’)
/opt/seafile/seafile-server-13.0.20/seahub/seahub/utils/password.py:26: SyntaxWarning: invalid escape sequence ‘\d’
has_numbers = bool(re.search(‘\d’, password))
/opt/seafile/seafile-server-13.0.20/seahub/seahub/base/middleware.py:163: SyntaxWarning: invalid escape sequence ‘.’
http_accept_regex = re.compile(“application/vnd.wap.xhtml+xml”, re.IGNORECASE)
/opt/seafile/seafile-server-13.0.20/seahub/seahub/group/utils.py:33: SyntaxWarning: invalid escape sequence ‘\w’
return re.match(‘[1]+$’, group_name, re.U)

Is that okay? or is my installation still not correct? running latest seafile 13.0.20

THanks again,

Ruediger


  1. ()()\w\s’.- ↩︎

There are Python syntax error because Python version incompatible. You can ignore them right now. We will fix them soon.

Great, thank you.

Just one more issue:

My WebDAV access is broken with version 13, seadav.conf shows enabled= true, just like in version 12. But browsing to seafile.mydomain.com/seafdav is automatically redirected to /seafdav/, showing that routing by caddy and nginx works, but it shows 502 Bad Gateway? What am I missing? How can I confirm that seafdav is running inside the container?

Please start a new thread.

1 Like