Seafile Windows client doesn't sync libraries with content
3,564 views
Skip to first unread message
Niclas
Oct 28, 2013, 10:01:33 AM10/28/13
to sea...@googlegroups.com
On two machines I'm running the latest Seafile client for Windows. Both users are logged on and can see their libraries listed in the client. But unfortunately they only can download empty libraries and none with files. The download of libraries with subfolderd and/or files gets stuck at 0% download progress and stays there until being
cancelled.
The client on one of the machines also brings the error message: "Failed to download blocks.".
When I empty the affected libraries thy can be downloaded without any hassle.
Is this a known issue ?
The client on one of the machines also brings the error message: "Failed to download blocks.".
When I empty the affected libraries thy can be downloaded without any hassle.
Is this a known issue ?
JiaQiang Xu
Oct 28, 2013, 10:24:33 AM10/28/13
to sea...@googlegroups.com
What's in the client's log? It's in C:\users\<username>\ccnet\logs\seafile.log.
--
You received this message because you are subscribed to the Google Groups "seafile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seafile+u...@googlegroups.com.
To post to this group, send email to sea...@googlegroups.com.
Visit this group at http://groups.google.com/group/seafile.
For more options, visit https://groups.google.com/groups/opt_out.
Niclas
Nov 6, 2013, 6:14:24 AM11/6/13
to sea...@googlegroups.com
Hi JiaQiang,
it's clear to see that subfolders with content are the problem.
Currently I have a library with 8 files and a folder with 20 files. The client starts downloading the library, stops at 8% and hangs. So it seems like the client is able to download the files in the main library but then fails when reaching the subfolder.
Libraries without folders can be downloaded completely and libraries without files but with a folder, containing files, refuse to download and get stuck with 0%.
The Seafile.log says:
[11/03/13 20:58:41] clone-mgr.c(368): Transition clone state for 173cf561 from [init] to [connect].
[11/03/13 20:58:45] clone-mgr.c(368): Transition clone state for 173cf561 from [connect] to [fetch].
[11/03/13 20:58:45] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'init') --> ('normal', 'check')
[11/03/13 20:58:46] processors/check-tx-v3-proc.c(260): protocol version is 5.
[11/03/13 20:58:46] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'check') --> ('normal', 'commit')
[11/03/13 20:58:46] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'commit') --> ('normal', 'fs')
[11/03/13 20:58:47] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'fs') --> ('normal', 'get-chunk-server')
[11/03/13 20:58:47] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'get-chunk-server') --> ('normal', 'data')
[11/03/13 20:59:08] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[...]
[11/03/13 20:59:50] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 20:59:50] transfer-mgr.c(532): Transfer repo '173cf561': ('normal', 'data') --> ('error', 'finished'): Failed to download blocks.
[11/03/13 20:59:51] clone-mgr.c(386): Transition clone state for 173cf561 from [fetch] to [error]: fetch.
[11/03/13 21:00:00] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:00:21] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:00:42] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
it's clear to see that subfolders with content are the problem.
Currently I have a library with 8 files and a folder with 20 files. The client starts downloading the library, stops at 8% and hangs. So it seems like the client is able to download the files in the main library but then fails when reaching the subfolder.
Libraries without folders can be downloaded completely and libraries without files but with a folder, containing files, refuse to download and get stuck with 0%.
The Seafile.log says:
[11/03/13 20:58:41] clone-mgr.c(368): Transition clone state for 173cf561 from [init] to [connect].
[11/03/13 20:58:45] clone-mgr.c(368): Transition clone state for 173cf561 from [connect] to [fetch].
[11/03/13 20:58:45] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'init') --> ('normal', 'check')
[11/03/13 20:58:46] processors/check-tx-v3-proc.c(260): protocol version is 5.
[11/03/13 20:58:46] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'check') --> ('normal', 'commit')
[11/03/13 20:58:46] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'commit') --> ('normal', 'fs')
[11/03/13 20:58:47] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'fs') --> ('normal', 'get-chunk-server')
[11/03/13 20:58:47] transfer-mgr.c(502): Transfer repo '173cf561': ('normal', 'get-chunk-server') --> ('normal', 'data')
[11/03/13 20:59:08] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[...]
[11/03/13 20:59:50] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 20:59:50] transfer-mgr.c(532): Transfer repo '173cf561': ('normal', 'data') --> ('error', 'finished'): Failed to download blocks.
[11/03/13 20:59:51] clone-mgr.c(386): Transition clone state for 173cf561 from [fetch] to [error]: fetch.
[11/03/13 21:00:00] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:00:21] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:00:42] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
JiaQiang Xu
Nov 6, 2013, 8:09:17 AM11/6/13
to sea...@googlegroups.com
As the log says, the client times out when connecting to the server.
Can you test the connection with 'telnet server-address 12001'?
--
Niclas
Nov 6, 2013, 10:33:01 AM11/6/13
to sea...@googlegroups.com
Yes, that's what's logged for repo 173cf561 which times out. But the client is connected to the server (green bulb icon in Seafile client's status bar), since other libraries (as long as they don't have a subfolder) can be downloaded and files are synchronized.
That the client is connected and downloading generally is possible shows the following part of the logfile:
[11/03/13 20:59:12] clone-mgr.c(368): Transition clone state for fbda0bcd from [init] to [fetch].
[11/03/13 20:59:13] transfer-mgr.c(502): Transfer repo 'fbda0bcd': ('normal', 'init') --> ('normal', 'check')
[11/03/13 20:59:13] processors/check-tx-v3-proc.c(260): protocol version is 5.
[11/03/13 20:59:13] transfer-mgr.c(502): Transfer repo 'fbda0bcd': ('normal', 'check') --> ('normal', 'commit')
[11/03/13 20:59:14] transfer-mgr.c(502): Transfer repo 'fbda0bcd': ('normal', 'commit') --> ('finished', 'finished')
And here another library with a subfolder which cannot be downloaded:
[11/03/13 21:02:28] clone-mgr.c(368): Transition clone state for 53496dfb from [init] to [index].
[11/03/13 21:02:28] clone-mgr.c(368): Transition clone state for 53496dfb from [index] to [fetch].
[11/03/13 21:02:29] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'init') --> ('normal', 'check')
[11/03/13 21:02:30] processors/check-tx-v3-proc.c(260): protocol version is 5.
[11/03/13 21:02:30] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'check') --> ('normal', 'commit')
[11/03/13 21:02:30] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'commit') --> ('normal', 'fs')
[11/03/13 21:02:31] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'fs') --> ('normal', 'get-chunk-server')
[11/03/13 21:02:31] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'get-chunk-server') --> ('normal', 'data')
[11/03/13 21:02:52] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:03:13] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:03:34] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:03:34] transfer-mgr.c(532): Transfer repo '53496dfb': ('normal', 'data') --> ('error', 'finished'): Failed to download blocks.
[11/03/13 21:03:34] clone-mgr.c(386): Transition clone state for 53496dfb from [fetch] to [error]: fetch.
That the client is connected and downloading generally is possible shows the following part of the logfile:
[11/03/13 20:59:12] clone-mgr.c(368): Transition clone state for fbda0bcd from [init] to [fetch].
[11/03/13 20:59:13] transfer-mgr.c(502): Transfer repo 'fbda0bcd': ('normal', 'init') --> ('normal', 'check')
[11/03/13 20:59:13] processors/check-tx-v3-proc.c(260): protocol version is 5.
[11/03/13 20:59:13] transfer-mgr.c(502): Transfer repo 'fbda0bcd': ('normal', 'check') --> ('normal', 'commit')
[11/03/13 20:59:14] transfer-mgr.c(502): Transfer repo 'fbda0bcd': ('normal', 'commit') --> ('finished', 'finished')
And here another library with a subfolder which cannot be downloaded:
[11/03/13 21:02:28] clone-mgr.c(368): Transition clone state for 53496dfb from [init] to [index].
[11/03/13 21:02:28] clone-mgr.c(368): Transition clone state for 53496dfb from [index] to [fetch].
[11/03/13 21:02:29] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'init') --> ('normal', 'check')
[11/03/13 21:02:30] processors/check-tx-v3-proc.c(260): protocol version is 5.
[11/03/13 21:02:30] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'check') --> ('normal', 'commit')
[11/03/13 21:02:30] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'commit') --> ('normal', 'fs')
[11/03/13 21:02:31] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'fs') --> ('normal', 'get-chunk-server')
[11/03/13 21:02:31] transfer-mgr.c(502): Transfer repo '53496dfb': ('normal', 'get-chunk-server') --> ('normal', 'data')
[11/03/13 21:02:52] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:03:13] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:03:34] block-tx-client.c(165): connect error: Connection timed out [WSAETIMEDOUT ].
[11/03/13 21:03:34] transfer-mgr.c(532): Transfer repo '53496dfb': ('normal', 'data') --> ('error', 'finished'): Failed to download blocks.
[11/03/13 21:03:34] clone-mgr.c(386): Transition clone state for 53496dfb from [fetch] to [error]: fetch.
Am Montag, 28. Oktober 2013 15:01:33 UTC+1 schrieb Niclas:
JiaQiang Xu
Nov 6, 2013, 8:27:47 PM11/6/13
to sea...@googlegroups.com
Actually you can only sync libraries without contents. Seafile use another port 12001 to transfer file contents. And whenever it connect that port, it times out. The client use a different port to tell whether the server is connected (10001).
--
JiaQiang Xu
Nov 6, 2013, 8:29:14 PM11/6/13
to sea...@googlegroups.com
It's most likely your firewall doesn't allow port 12001. The packets sent to the server are all dropped so the client times out.
Niclas
Nov 7, 2013, 6:37:09 AM11/7/13
to sea...@googlegroups.com
Ah, I see.
Thanks for this information. I will check my firewall settings concerning port 12001. But nevertheless, downloads of folders are not possible at the moment. :)
Besides, how many ports and which ones does the client use ?
So currently I have at least three:
1. 12001 for file transfer
2. 10001 for server connection (check)
3. 1234 (custom port) which is set in Seafile config. What exactly is this port good for ? To connect to the repository ?
4. Other port(s) ?!
Thanks for this information. I will check my firewall settings concerning port 12001. But nevertheless, downloads of folders are not possible at the moment. :)
Besides, how many ports and which ones does the client use ?
So currently I have at least three:
1. 12001 for file transfer
2. 10001 for server connection (check)
3. 1234 (custom port) which is set in Seafile config. What exactly is this port good for ? To connect to the repository ?
4. Other port(s) ?!
Lingtao Pan
Nov 18, 2013, 11:31:53 PM11/18/13
to sea...@googlegroups.com
We have find the cause of this problem (WSAETIMEDOUT). You have mis-configured SERVICE_URL in ccnet.conf
Niclas
Nov 19, 2013, 2:58:39 AM11/19/13
to sea...@googlegroups.com
How does the SERVICE_URL have to be configured ? Should it contain the local IP instead off the public one ?
Mine is: SERVICE_URL = http://mydns.dnsservice.com:8000
Strange thing is that the old client (1.5x) (running on Windows Vista 32-Bit) successfully synchronizes the libraries WITH folders AND content. Obviously only the latest client 2.x doesn't do this (running on Windows 7 32-Bit, 64-Bit and Windows 8 32-Bit).
Mine is: SERVICE_URL = http://mydns.dnsservice.com:8000
Strange thing is that the old client (1.5x) (running on Windows Vista 32-Bit) successfully synchronizes the libraries WITH folders AND content. Obviously only the latest client 2.x doesn't do this (running on Windows 7 32-Bit, 64-Bit and Windows 8 32-Bit).
Lingtao Pan
Nov 19, 2013, 3:06:59 AM11/19/13
to sea...@googlegroups.com
During the syncing, the client will try to connect the server via domain "mydns.dnsservice.com". Make sure the client can connect the server with this domain.
--
You received this message because you are subscribed to a topic in the Google Groups "seafile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/seafile/xQpcdT_HowE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to seafile+u...@googlegroups.com.
JiaQiang Xu
Nov 19, 2013, 3:25:35 AM11/19/13
to sea...@googlegroups.com
Can you tell me what's your SERVICE_URL in a private email?
--
You received this message because you are subscribed to the Google Groups "seafile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seafile+u...@googlegroups.com.
Niclas
Jan 14, 2014, 6:00:57 AM1/14/14
to sea...@googlegroups.com
It's: http://acme.dyndns.com:8000 (which is not the real address but just to show how it looks like).
Connecting generally is possible and the client is able to download and synchronize - as long as it doesn't have to to download files which are stored in a folder inside a library. The folder itself can be downloaded and synchronized as long as iti is empty. As soon as it contains files the Seafile clients starts downloading, then reaches the folder and fails.
The seafile.log in the ccnet folder says:
[...]
transfer-mgr.c(592): Transfer repo '09cfbdad': ('normal','data') --> ('error','finished'): Failed to upload blocks.
sync-mgr.c(425): Repo 'MyShare' sync state transition from uploading to 'error': 'Error ocured in upload'.
[...]
"Failed to upload blocks" is also the error message the client shows in it's download queue.
But in general - as said - up- and downloading is possible as long as I don't try to synchronize files being stored in a folder.
Connecting generally is possible and the client is able to download and synchronize - as long as it doesn't have to to download files which are stored in a folder inside a library. The folder itself can be downloaded and synchronized as long as iti is empty. As soon as it contains files the Seafile clients starts downloading, then reaches the folder and fails.
The seafile.log in the ccnet folder says:
[...]
transfer-mgr.c(592): Transfer repo '09cfbdad': ('normal','data') --> ('error','finished'): Failed to upload blocks.
sync-mgr.c(425): Repo 'MyShare' sync state transition from uploading to 'error': 'Error ocured in upload'.
[...]
"Failed to upload blocks" is also the error message the client shows in it's download queue.
But in general - as said - up- and downloading is possible as long as I don't try to synchronize files being stored in a folder.
JiaQiang Xu
Jan 14, 2014, 7:15:11 AM1/14/14
to sea...@googlegroups.com
I can't explain why. You can try the latest server. After upgrading the server, you should:
- Remove the server's account from the client
- Restart the client
- then re-add the account
See if this works.
JiaQiang Xu
Jan 14, 2014, 7:16:41 AM1/14/14
to sea...@googlegroups.com
Message has been deleted
Message has been deleted
Shuai Lin
Mar 30, 2014, 10:11:43 PM3/30/14
to sea...@googlegroups.com
Hi,
Have you opened the ports in your firewall settings?
https://github.com/haiwen/seafile/wiki/Firewall-settings-for-seafile-server
LinHave you opened the ports in your firewall settings?
https://github.com/haiwen/seafile/wiki/Firewall-settings-for-seafile-server
On Sat, Mar 29, 2014 at 8:03 PM, Niclas <t1t4...@googlemail.com> wrote:
Ok, currently running Seafile Server 2.1.5 on Wheezy Raspberry Pi and Seafile Client 2.1.2 on Windows 7 64-Bit. Issue still exists.
Library without folders can be synced without a problem, libraries with one or more folders cannot be downloaded. Error message: Failed to download blocks.
Connection via all ports should be fine. Otherwise the client wouldn't even download "plain" libraries containing files only.
Am Montag, 28. Oktober 2013 15:01:33 UTC+1 schrieb Niclas:
--
You received this message because you are subscribed to the Google Groups "seafile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seafile+u...@googlegroups.com.
To post to this group, send email to sea...@googlegroups.com.
Visit this group at http://groups.google.com/group/seafile.
For more options, visit https://groups.google.com/d/optout.
Niclas
Apr 7, 2014, 4:42:12 AM4/7/14
to sea...@googlegroups.com
Hi Shuai Lin,
yes, I did so. Synchronisation generally is possible - as long as the library doesn't contain a folder ! Empty libraries or libraries with files on in it are no problem. So i the port wouldn't have been opened even they wouldn't be synchronized. Right ?
yes, I did so. Synchronisation generally is possible - as long as the library doesn't contain a folder ! Empty libraries or libraries with files on in it are no problem. So i the port wouldn't have been opened even they wouldn't be synchronized. Right ?
Shuai Lin
Apr 7, 2014, 6:29:50 AM4/7/14
to sea...@googlegroups.com
Hi,
Your error message says "Failed to download blocks", by default, block transfer uses port 12001 of the server, that's why I asked you to ensure you have opened the all the ports listed in https://github.com/haiwen/seafile/wiki/Firewall-settings-for-seafile-server
Your error message says "Failed to download blocks", by default, block transfer uses port 12001 of the server, that's why I asked you to ensure you have opened the all the ports listed in https://github.com/haiwen/seafile/wiki/Firewall-settings-for-seafile-server
Niclas
Apr 28, 2014, 4:12:09 AM4/28/14
to sea...@googlegroups.com
Hi all,
problem seems to be solved. The solution wasn't the port (all required ports are open !) but the "blocks" directory in the Seafile client installation folder !
Yesterday I renamed the folder and installed the latest Windows client as an upgrade over the existing previous installation. Afterwards I eventually was able to download/sync all my libraries WITH folders and subfolders !
problem seems to be solved. The solution wasn't the port (all required ports are open !) but the "blocks" directory in the Seafile client installation folder !
Yesterday I renamed the folder and installed the latest Windows client as an upgrade over the existing previous installation. Afterwards I eventually was able to download/sync all my libraries WITH folders and subfolders !
Am Montag, 28. Oktober 2013 15:01:33 UTC+1 schrieb Niclas:
Niclas
May 14, 2014, 8:02:44 AM5/14/14
to sea...@googlegroups.com
Well, problem occurs again. After having worked withtout any problems for some days now there are again some libraries which cannot be synched: "Failed to download blocks".
Will install 3.0.4 tonight and see. But...to be honest: I doubt that it will work afterwards.
Will install 3.0.4 tonight and see. But...to be honest: I doubt that it will work afterwards.
Am Montag, 28. Oktober 2013 15:01:33 UTC+1 schrieb Niclas:
Reply all
Reply to author
Forward
0 new messages