Seafile documentation, repositories, client libraries: what, where, how. Should I be worried?

Hi there,

I’ve been using seafile for a long time now, mostly for private things. Recently, I’ve started looking into providing seafile to some of my clients, since it’s a great on-premise solution. I’m currently running two pro licensed v10s and am mostly happy with what I came up with. However, this was already a not so easy undertaking, since the documentation seems to be all over the place, same for actual code on github. I spend hours trying to piece together the correct format, settings, libraries, code snippets etc to finally get to a working and stable environment. But ok, I can kind of live with that even though it shouldn’t be the case, I guess. The forum and a lot of patience helps…

However, it gets really complicated whenever I try to do sth a little “out of the ordinary”(?) like integrating another system with seafile through the api or via settings. Again, I found about three different python bindings, some of them “official” but not having really been updated since - it feels like - the last century. Python3 support? None official? Really? Then why offer the libs at all, if this is end-of-life? I mean… The javascript api has been updated not too long ago but a simple npm install makes me loose more time then I’ve ever spent on a published npm module, hunting down dependencies, fixing auditing issues etc. But maybe I’m just using the wrong libraries? Well, check the docs again. And again: three different documentations in as many different locations. Whenever I work on seafile, I’ve got about 10-15 different tabs open for one issue. This can’t be safe.

So, if anyone would be able to tell me where to find:

  1. information about actually maintained libraries, js, python, go, i don’t care, be they on github, in a .tgz, another repo. whatever. Piecing together information from as many as three different usernames (there might be more…?) on github to get to working solutions is just not a solution.
  2. information as to the actual, updated and maintained documentation for these. To be fair, whenever I think I’ve found the correct code for sth on github, documentation from within the repo (if it exists), seems kind of up-to-date, but again, all over the place.
  3. I’ve found that the best and most recent information is often on a seatable maintained by the devs. Is there a list of all accessible (and maintained!) tables regarding the seafile eco system?
  4. your own take on the actual appropriateness of using seafile for SMEs.

I would really appreciate this, before I decide to switch for lack of good documentation and best practices. I know that many large organisations rely on seafile and it works well for them, I guess the support for these is great, but for SMEs, I’m not sure this is a right fit anymore. Convince me of the contrary, because I really like the product? Thanks.

Sorry for the rant, but I’ve lost so much time with this, it’s just incredible… Seafile, in my opinion, would really, really profit from having someone go over the entire documentation, making sure it is accurate and relevant, not outdated and that it can be found in one central location. It’s a great product but it needs some definite attention in this regard.

Feel free to disagree and let me know why?


p.s.: I’m putting this in feature request for lack of an overarching category. Move it if you feel it belongs somewhere else. Thank you.


Can’t really help with your questions. Just wanted to say that I strongly agree with your take!

1 Like

The official documentation and support material related to Seafile is on this page: Seafile - Open Source File Sync and Share Software

Besides Restful API, there is no officially supported SDKs for Seafile so far.

The current python SDK ( is not will maintained. We will give it an update.

May I ask you what document do you missing?

Hi @daniel.pan

Well, this is good information and I thank you for your swift reply.

Your answer for 3) is very helpful and this was a great find!

As for the Restful API, it’s kind of hard to trust this information if the page hasn’t been updated for 4 years and the examples linked in the API Docs for e.g. python is 8 years old and not actually working but you said you were going to work on those, so that’s great. On top, if, like me, you create library API tokens instead of a global owner/admin token, the API is heavily restricted in functionality and this is something I only found out by searching through some forum posts like this. It then becomes clear, looking at the specific api doc. Before that I didn’t know there were different API tokens and hunted for reasons in logfiles and online for an unspecific error such as a general 403 albeit correct credentials.

As for my comment on “the documentation being all over the place”, I think it might have to do with some old documentation still being accessible online? Usually recognisable by missing images/ css formatting but not always.

That was the reason I wrote the post in the first place because it is the general experience I’ve had when making changes to seafile, be it for integrating onlyoffice (from missing document formats in the allowed list for editing to docker internal routing etc), elasticsearch (official install via docker compose didn’t work for some reason, tried to fix but haven’t gotten around to it for lack of time), csrf settings, GDPR, etc… Some of the information is in the manual, some is in the forum etc. An issue with the notification server that kept me on my toes (that was then fixed upstream, if I remember correctly), etc. And whenever something doesn’t “work out of the box”, people google/… it. And then starts the rabbit hole you can get stuck in. Specifically if there’s old and outdated information out there.

So maybe the goal should be to remove all old documentation that is still being referenced by the search engines, clean up github code repos for old and outdated information and code and so on. Seafile is already a great product and has so much potential and it deserves clean and accurate documentation maybe some (community) tutorials/ walkthroughs etc.

I’ll give another simple example: When following Support->Admin Manual, you end up being told the document has moved. Why then keep this document in place with the menu structure and possibly outdated(?) information? A simple 301 to the new URI would be better?

On the other hand, I know that projects can grow naturally and can then be hard to keep in good shape. You reacting right away (cf. #228 to what I said is a testament to your willingness to make your customer experience great. So kudos and thanks!

EDIT: Funny, looking at this I found this link: Folder does not exist :wink: It should probably be that link

There have been several threads on this same subject. If you wander off the norm, the documentation is all over the place. I probably burnt 4+ hours, maybe more, trying to get a clean install of Seafile 10 working. Mainly because the documentation missed a key Python module.

Interesting that I come here today for looking something about the Rest API and you found your thread at the top.
I’m looking for a solution to upload directly files to Seafile through an upload firm in php.
But the manual is old and some pages are missing. So I ‘m in the same position like the thread opener.