Seafile community edition 10.0 is ready!

Seafile community edition 10.0 is ready.

Here are major changes in version 10.0:

  • Update Python dependencies and support Ubuntu 22.04 and Debian 11
  • Add a new notification server
  • Support a user to generate multiple share links for a single file/folder

The notification server enables desktop syncing and drive clients to get notification of library changes immediately using websocket. There are two benefits:

  1. Reduce the time for syncing new changes to local
  2. Reduce the load of the server as periodically pulling is removed. There are significant reduction of load when you have 1000+ clients.

The notification server works with Seafile syncing client 9.0+ and drive client 3.0+.

Please follow the document to enable notification server: seafile.conf - Seafile Admin Manual


Congrats on the release! I run seafile 10 community with nginx. For the new notification server: Do i need to port forward it manually or is there a new nginx config coming? Right now i don’t see anything in the documentation.

that is great news!

will there also be updated linux clients in the official repo? they’re still at 8.0.7, released a year ago, and from what you write are unable to use the notification feature, thus not reducing any load.

1 Like

Good question. We have updated the document for the Nginx config:


Hi! Thank you for your work!

Since i’ve upgrading to 10.0.1 i’ve several messages in syslog:[454351]: 2023/04/11 11:51:51 http: superfluous response.WriteHeader call from main.appHandler.ServeHTTP (server.go:309)

What does it mean?


Upgraded two servers, one went fine, the other has errors now: “502 Bad Gateway”

Log simply says:

2023/04/11 15:52:16 [error] 744#744: *559 connect() failed (111: Connection refused) while connecting to upstream, client:, server:, request: "GET / HTTP/1.1", upstream: "", host: ""

Do you have seafile / seahub log files with some errors ? If yes, can you share the output here ?

I’m not seeing much more in mine. When I start Seafile I do see this, which I don’t see on my other server:

/opt/seafile/seafile-server-10.0.1/upgrade# /etc/init.d/seafile-server start

** Message: 16:17:00.130: seafile-controller.c(621): No seafevents.

Traceback (most recent call last):
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/bin/gunicorn”, line 5, in
from import run
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/gunicorn/app/”, line 9, in
from import Application
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/gunicorn/app/”, line 11, in
from gunicorn import util
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/gunicorn/”, line 25, in
import pkg_resources
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/pkg_resources/”, line 88, in
from pkg_resources.extern import platformdirs
File “”, line 971, in _find_and_load
File “”, line 955, in _find_and_load_unlocked
File “”, line 658, in _load_unlocked
File “”, line 571, in module_from_spec
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/pkg_resources/extern/”, line 52, in create_module
return self.load_module(
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/pkg_resources/extern/”, line 37, in load_module
File “/opt/seafile/seafile-server-10.0.1/seahub/thirdpart/pkg_resources/_vendor/platformdirs/”, line 5
from future import annotations
SyntaxError: future feature annotations is not defined

have you updated the python modules?

@daniel.pan there seems to be a small mistake in the config with:
proxy_set_header Upgrade $http_upgrade.
After i removed the backslash in \$http_upgrade everything started working fine.

Currently Linux client cannot use notification server. The websockets library we use (libwebsockets) is too old on most distributions.

what is the plan for linux clients? they’re stuck at version 8.0.7, current is 9.0.1, so linux users are already missing out on some fixes and features. the 2FA issue that the clients have with non-root installations is unsolved for one year now. how are you planning to handle this in the future? will there ever be updates to the linux clients?

1 Like

Hi drmartin,
I’ve seen that same error on one of my servers. After much research and troubleshooting, in my case upgrading from Python 3.6 to something higher (3.9 in my case) fixed the problem.

This was not super easy as my Linux distro defaults to 3.6 and upgrading to 3.9 meant manually changing the symbolic link for /usr/bin/python3 to point to python3.9 instead of the default of 3.6.

My understanding from my research is “future feature annotations” is a feature/command in pythons >= 3.7, but I’m not a python person, so I could be wrong.

The linux clients will continue to upgrade. The notification server support is disabled for Linux clients since the 3rd party library is unavailable. Other updates are not affected.

We didn’t notice the non-root 2FA problem. We’ll look into it.

1 Like

ideally, there should simply be a check for the installed version of the libwebsockets library during configure before the build. the notifiation feature could then be activated automatically depending on the result. if users manage to manually update the library, they could simply rebuild the client locally to also get that feature.

i’m looking forward to getting updated deb packages, thank you :slight_smile:

the changelog for seafile client 9.0.2 states it adresses an UI issue for 2FA, were you able to fix the problem i described?

however, the linux clients have still not been updated since 8.0.7, which happened one year ago. when will there be up-to-date linux clients?

It’s not fixed yet.

The debian packages will be updated recently.

Has anybody got the new notification server to work?

I’ve added the relevant blocks to my NGINX config, as described above, and the following to seafile.conf

enabled = true
host =
port = 8083
log_level = info
jwt_private_key = 'xxx'

After restarting the docker container, if I access /notification/list/, I get “Sorry, but the requested page could not be found.” Any ideas?

I may have missed something, but I don’t see what you’re looking at this endpoint.

There is the /notification/ping endpoint you can access from your browser, which should answer {"ret": "pong"}. I suppose it’s designed to be enough to test the notification server.

Now if you want a more in depth test, you can open a websocket, for example in your browser console.

ws = new WebSocket('ws://')

Then generate a valid jwt token signed with your jwt_private_key (you’d better to set a dummy key without fancy characters). I used this tool (have I to say you shouldn’t copy production secrets to some random web app?) to build the token with the following payload:

  "repo_id": "<<some repo id>>",
  "username": "<<some user email>>",
  "iat": 1684333194,
  "exp": 2684333194

Then send the subscription message:

ws.send('{"type":"subscribe", "content":{"repos":[{"id":"<<same repo id>>", "jwt_token":"<<the jwt token>>"}]}}')

Edit or create some files in the library and, finally, get a notification event:


And you’re 100% sure the notification server is working fine.

1 Like

Have you checked notificationserver.log for messages?