Connecting server... and not moving forward

Hi!

I have the latest debian server (6.0.9) and the latest clients for mac and win 10 running.
I have about 32 libraries and not even 2500 files in total.

some libraries / folders are about 290-350mb in size and it is not possible to sync them. I always get “connecting server…” on any client.

The logs show on win client: (seafile.log)

[04/18/17 20:57:06] sync-mgr.c(702): Repo 'Meine Bibliothek' sync state transition from 'synchronized' to 'committing'.
[04/18/17 20:57:06] repo-mgr.c(3730): All events are processed for repo 91d5d6c5-b012-4563-9109-ccc943d8d5b2.
[04/18/17 20:57:06] sync-mgr.c(702): Repo 'Meine Bibliothek' sync state transition from 'committing' to 'initializing'.
[04/18/17 20:57:17] clone-mgr.c(840): Transition clone state for 159a5125 from [connect] to [canceled].
[04/18/17 20:57:27] clone-mgr.c(840): Transition clone state for 159a5125 from [init] to [connect].

The serverside: (ccnet.log)

[04/18/17 18:45:29] ../common/session.c(132): using config file /var/www/seafile/conf/ccnet.conf
[04/18/17 18:45:29] ../common/session.c(455): socket file exists, delete it anyway
[04/18/17 18:45:29] ../common/session.c(484): Listen on /var/www/seafile/ccnet/ccnet.sock for local clients
[04/18/17 18:45:29] ../common/session.c(290): Update pubinfo file
[04/18/17 18:45:30] ../common/session.c(398): Accepted a local client
[04/18/17 18:45:30] ../common/session.c(398): Accepted a local client
[04/18/17 18:45:30] ../common/session.c(398): Accepted a local client
[04/18/17 18:45:30] ../common/session.c(398): Accepted a local client
[04/18/17 18:45:34] ../common/session.c(398): Accepted a local client
[04/18/17 18:45:34] ../common/peer.c(943): Local peer down
[04/18/17 18:46:11] ../common/session.c(398): Accepted a local client
[04/18/17 18:46:11] ../common/session.c(398): Accepted a local client
[04/18/17 18:46:11] ../common/session.c(398): Accepted a local client

seafile-django-request.log:

2017-04-18 18:56:41,166 [WARNING] django.request:170 get_response Not Found: /seafhttp/protocol-version

BTW: I can connect and download files with the webgui.
seafdav is enabled

my seafile.conf looks like this:

[fileserver]
port = 8082

[database]
type = mysql
host = 127.0.0.1
port = 3306
user = user
password = password
db_name = seafile-db
connection_charset = utf8

and my ccnet.conf

[General]
USER_NAME = Seafile
ID = 00e2380ae70XXXXXXXXXXXXXXXXXXXXXXXXX
NAME = Seafile Server
SERVICE_URL = http://seafile.nsa.gov:8000

[Client]
PORT = 13419

[Database]
ENGINE = mysql
HOST = 127.0.0.1
PORT = 3306
USER = seafile
PASSWD = password
DB = ccnet-db
CONNECTION_CHARSET = utf8

Please help me.

PS.: seaf-fsck has no problems

Thanks

push…

This line leads me to believe that the client simply cannot access the HTTP API of the Seafile Server (which is a different part than the Seahub Server!).

Since you apparently do not use an HTTP reverse proxy like Apache or Nginx, you need to take the port from your seafile.conf:

And add it in the FILE_SERVER_ROOT of your seahub_settings.py:
FILE_SERVER_ROOT = 'http://seafile.nsa.gov:8082'

Does this help?

Thanks, I will give it a try. But I can access some Folders. I can setup new syncs…
Only some (bigger) folders have this problem.

Regards

Update: It does not change anything. I can even see the “last changed” date at this folders, but can not sync them.

@schlarbm that did not change anything.

btw: I am able to transfer and sync small directories without any problem. And the android app can download from the not synced directories (since this app is not able to “sync”)

Regards

@Christian_Adelbrecht Did you find a solution for this? I’ve got a similar problem but it does not seem to be connected to the size of the library… Some libraries sync, some don’t.

@deryo

What do the logs say about the issue?

I found out what the problem is: Old format libraries (created with server versions pre 3.0) cannot be synced by http(s). The affected libraries were toooooo old.
More: https://github.com/haiwen/seafile/issues/975#issuecomment-67431807
I don’t understand why this isn’t published somewhat more prominently.

I believe the changelog mentions it whenever a version is released that affects the functionality somehow. For example, the 6.2 version, mentions that fastcgi is going away.

I remember from past upgrades there being mention of updating database files from older versions, but that’s been a while since the last time a version changed the database structure.

Hi wthess, I really appreciate your help, but did you even read through the issue 975 before posting? Especially this comment?

You have been guessing a lot in the other thread about the “argument can’t be null” problem and now here you ‘believe’ that the changelogs mention this. They don’t. The server changelog since version 1.5 can be found here.

I really appreciate help and sometimes the right questions from an outsider lead to findig the answer to a problem. But guessing and believing is nothing to work with when facts are available.

I don’t even understand why you posted the above comment. To show me that it’s my own fault because I did at some time not follow update procedures? To help the reputation of seafile? Also we were talking about libraries and not databases.

Please keep up your good spirit in helping other people but also please keep your posts relevant and if you don’t have the time to really look into something then just don’t reply.

Again, thanks for your help.

You asked why something wasn’t published more prominently. I answered that it was mentioned in the past. Simple as that. In this particular case, we are talking about something all the way back from version 3… The manual has been updated many times since then, and it’s been removed.

And, there is no “guessing” as you state. I’ve coded for nearly 30 years and also done technology and IT support for nearly as long. I’ve helped many people here and in other forums solve problems, even remoting into their machines to take care of it for them when they asked. It’s called “process of elimination”. “Argument Can’t Be Null” is a general error message and takes digging through code since arguments are passed through code, and there can be many reasons arguments fail to pass. Therefore, the process of elimination is necessary to narrow it down.

However, if you don’t care to try the things that others suggest for you when you post a question out here, that’s your prerogative. We are all here to learn, up to and including the developers of Seafile so that they can release patches to future versions.

1 Like

As for “not having the time”, I spent a good 4 or 5 hours reading through the code on that error in order to narrow the problem down for you. I think I spent more than enough time, considering I’m not paid to do it. And, you are welcome, btw.