Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP/HTTPS sync #975

nandovici opened this issue Dec 17, 2014 · 14 comments

HTTP/HTTPS sync #975

nandovici opened this issue Dec 17, 2014 · 14 comments


Copy link

@nandovici nandovici commented Dec 17, 2014


I am trying to run the https synchronization.

  • Seafile server version 4.01;
  • Seafile windows client version 4.03.
    I can see libraries and documents in the browser, but I can not have the client sync properly running. It seems that the client keeps trying to connect on the port 10001, wich is closed.
    The "Enable file syncing with HTTP protocol" is checked in the settings.

This is a slice of the ccnet.log on the client:

[12/17/14 18:35:07] ccnet-daemon.c(193): starting ccnet client 4.0.3
[12/17/14 18:35:07] ccnet-daemon.c(195): ccnet source code version    8bca42a29e944898c2be645e7c8a3d326f8c4084
[12/17/14 18:35:07] ../common/session.c(395): Listen on 13419
[12/17/14 18:35:07] ../common/session.c(267): Update pubinfo file
[12/17/14 18:35:08] ../common/session.c(375): Accepted a local client
[12/17/14 18:35:08] ../common/session.c(375): Accepted a local client
[12/17/14 18:35:08] ../common/session.c(375): Accepted a local client
[12/17/14 18:35:08] ../common/session.c(375): Accepted a local client
[12/17/14 18:35:08] ../common/session.c(375): Accepted a local client
[12/17/14 18:35:08] ../common/session.c(375): Accepted a local client
[12/17/14 18:35:08] ../common/processors/rcvcmd-proc.c(492): Add server 2e0924b1
[12/17/14 18:35:08] ../common/connect-mgr.c(364): [Conn] Start outgoing connect to (null) 2e0924b194)
[12/17/14 18:35:18] ../common/connect-mgr.c(220): [Conn] peer (null)(2e0924b194) connection fails

Thank you in advance.

Copy link

@kgbvax kgbvax commented Dec 18, 2014

Same story here, apparently.

Copy link

@freeplant freeplant commented Dec 18, 2014

The ccnet.log is in-relavant. Please check seafile.log at the client side.

Copy link

@killing killing commented Dec 18, 2014

There are 2 possible cause:

  1. Your libraries are created before 3.0 version
  2. You use a self-signed certificate on the server. You need to check the "Disable verify certificate" option in the client. And restart the client.

Copy link

@killing killing commented Dec 18, 2014

As answered in
using SNI requires an up-to-date version of libcurl and openssl. If you're using Linux, just check your system's library version. If you're using Windows or Mac, the bundled version is already new enough.

Copy link

@nandovici nandovici commented Dec 18, 2014

I solved.

My libraries were created before 3.0 version!

Creating a fresh new library I can syncronize via HTTPS with no problem.

Thank you very much!

Copy link

@fenderle fenderle commented Jan 6, 2015

Why do older libraries not sync through http? Is it possible to convert them or fix the problem somehow using config changes?

Copy link

@killing killing commented Jan 6, 2015

@fenderle The old format lacks information to support the new protocol, like file timestamps. You can migrate the data to a new library by copying data on web. But history would be lost...

Copy link

@TimWolla TimWolla commented Jan 11, 2015

@fenderle The old format lacks information to support the new protocol, like file timestamps. You can migrate the data to a new library by copying data on web. But history would be lost...

Is it possible to provide an automated migration path? e.g. by setting the change time of every file to the commit time. Redownloading 20+ gigabytes using a small pipe is not fun :-( But I don't care about an automated migration on the server taking several hours.

Copy link

@palday palday commented Jul 14, 2015

The automated path would be very useful, especially since the claim on the website is "Now we use HTTP/HTTPS sync only. The old TCP sync protocol will no longer be used. The using of port 10001 and 12001 becomes history. They are not needed at all." In light of this thread, this is patently false, and this is even noted in the source code.

Copy link

@raimue raimue commented Aug 22, 2017

The linked guide for migrating an old Seafile library to the new format is no longer reachable. I am being stuck with some older libraries, but unable to find any more information on this. Was this forum post archived somewhere?

Copy link

@TimWolla TimWolla commented Aug 22, 2017

@raimue I don't have the contents of the post any more, but I can provide you the link of the migration software I wrote, but without giving any support or help whatsoever:

Copy link

@raimue raimue commented Sep 1, 2017

@TimWolla Thank you very much for sharing the tool, that allowed me some insight in what is required. While I got the tool to build, in the end I still decided it would be the future-proof solution to just give up on history and migrate these libraries by re-uploading the files. The only library I could not get converted was the "My Library Template". As I am not using it at the moment, I'll will just leave it like that for now.

Copy link

@shoeper shoeper commented Sep 15, 2017

I found the text from the post in my email archive. Here is is:

This is from @TimWolla

I finished converting my complete seafile installation a few days before and polished my program a little as well.
What my program can do:

    Converting an unencrypted library from the „V0“ to the „V1“ library format while preserving the version history

What my program cannot do:

    Converting an encrypted library (I do not need this myself)
    Brew some coffee
    Everything else

Please note:

    While I successfully converted my own unencrypted libraries I cannot guarantee that it won't delete all your precious data, keep backups and play safe.
    You have to shutdown seafile before starting a conversion (or at least ensure that the library that's being converted is not modified).
    It is pretty slow (this is an inherent property of the conversion process). Depending on the exact size of structure of the library it may take a few hours or even days.

How to use?

    Find the UUID of the library you want to convert (it's in the address bar of the web interface)
    Shut down seafile
    Find the root commit via: SELECT commit_id FROM Branch WHERE repo_id = '…' (insert your UUID here)
    Run ./seaf-fix /srv/seafile/seafile-data/storage /srv/seafile/seaf-fix/target/ UUID commit_id (you'll know that your paths are)
    Wait a little bit more until something like this appears: Done, your new root is: b0d58206779cc1299a4dde13950dfe091cc1a704
    Ensure your backup is good, once again
    UPDATE Branch SET commit_id = 'b0d58206779cc1299a4dde13950dfe091cc1a704' WHERE repo_id = 'UUID' (adapt as needed)
    Repeat step 4 to 8 for every sub library: SELECT repo_id FROM VirtualRepo WHERE origin_repo = 'UUID'.
    You have to symlink /srv/seafile/seafile-data/storage/fs/SUBLIBRARY_UUID/ to /srv/seafile/seafile-data/storage/fs/UUID/ (as both share the same FS directory)
    rm -rf /srv/seafile/seafile-data/storage/commits/UUID/ (for every library you converted)
    rm -rf /srv/seafile/seafile-data/storage/fs/UUID/ (for every library you converted)
    Move every folder from /srv/seafile/seaf-fix/target/commits/ to /srv/seafile/seafile-data/storage/commits/
    If you have sublibraries: Merge the contents of the /srv/seafile/seaf-fix/fs/ folders into the folder with the UUID of the root library
    If you have sublibraries: Fix the base_commit inside VirtualRepo (you have to search the output of the parent library for that, sorry).
    Move /srv/seafile/seaf-fix/target/fs/UUID to /srv/seafile/seafile-data/storage/fs/UUID.
    Run (it should not find any issues)
    Run --dry-run (it should not find any issues either)
    Start seafile again and check whether your library looks fine.


MIT License.
Where to get it?

It comes in three prebuilt flavors. One version for servers with lots of RAM to spare (it uses up to 25 GB of RAM on my box, YMMV), another one for smaller boxes (about 2 GB of RAM, YMMV) and a third with only the minimal amount of RAM. You can adapt it yourself in the source code on this line: (6 Millionen = 25 GB, 400k = 2 GB). Obviously the more RAM you have to spare the faster it is. The binaries are static binaries built using GHC inside a Docker container (Debian Jessie), they should work on every Linux out there, though.

Both the git tags, as well as the binaries can be verified using this GPG key:

pub   4096R/094168AF 2013-10-04
      Key fingerprint = 3033 55CF 8E33 D090 86CB  28F6 8FF7 5566 0941 68AF
uid                  Tim Düsterhus (git signing) <>
sub   4096R/127D597F 2013-10-04

Git repository:

25G RAM version:
2G RAM version:
Minimal version:


Hash: SHA256

6166144eb0eb6b68f7b94aa6ea5e7904c1494d5f72c3dde97a4c67e2cb8e9a97  seaf-fix-0
f131ad42c8940e9e4bdbc4814420e0ecc0876d70cf700cc5143b25f994b3246f  seaf-fix-400000
c44818d20cec4622bf04a59ce5f1fa6e5f235c1703dc4242f9eea381b33ebb4e  seaf-fix-6000000
Version: GnuPG v1


And here is one of the more relevant replies: (also by @TimWolla)

Hash: SHA256


sure. I just uploaded a `seaf-fix-infty` with the following SHA-256 checksum to GitHub:

    6c5b77ba1a860d7aef9fdb87bc1dac788d053e3341d15b584781164f209fddc4  seaf-fix-infty

This version completely removes the clearing of the internal cache, therefore it’s memory
usage will grow without bounds. Make sure to not overwhelm your server and stop services
that should not be killed by the OOM killer (such as your database server).

Best regards
Version: GnuPG v1


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants