Seafile 12.0.6 Linux AppImage and Android App Issues

Seafile Client
, ,
1

Hi after not using Seafile for a longer time, I decided to use it again.
I directly tried out 12.0.6 Docker and the setup went well.
Access to the server works perfectly via Browser, with Letsencrypt signed SSL certs.

However, with the Clients on Linux and Android, I cannot use it correctly.

On Linux (AppImage 9.0.11), I can perfectly log in to my account. However, when I try to sync a library, I receive the message “seafile client failed to establish secure connection”.
If I set “do no verify server certificate in HTTPS syncing” on the client, syncing works well.

On Android (from PlayStore or F-Droid v 3.0.6), I can also log in to my account but then it takes FOREVER to load the list of libraries. Sometimes, it even does not finish. Also if it has loaded the libraries, loading file lists, is again the same.
Downloading or uploading files with the app does not work at all.

On the server, I could not find any suspicious entries in the logs (seafile-data/logs/var-log/nginx/error.log, seafhttp.error.log seahug.error.log seafdav.error.log)

2

In your seahub_settings.py file do you have FILE_SERVER_ROOT = set up correctly? It should look like ‘https://test-seafile.your.domain.com/seafhttp’. I think if that is wrong (for example if it points to an IP instead of name) that it can cause the sorts of problems you are describing.

1 Like
3

Thank you, @tomservo
It is already set up like this:

Summary 
SERVICE_URL = "https://seafile.mydomain.de"

CSRF_TRUSTED_ORIGINS = ["https://seafile.mydomain.de"]

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'seahub_db',
        'USER': 'seafile',
        'PASSWORD': 'mysqlpw',
        'HOST': 'db',
        'PORT': '3306',
        'OPTIONS': {'charset': 'utf8mb4'},
    }
}


CACHES = {
    'default': {
        'BACKEND': 'django_pylibmc.memcached.PyLibMCCache',
        'LOCATION': 'memcached:11211',
    },
    'locmem': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    },
}
COMPRESS_CACHE_BACKEND = 'locmem'

TIME_ZONE = 'Europe/Berlin'
FILE_SERVER_ROOT = 'https://seafile.mydomain.de/seafhttp'

Do you have a pointer where I could look for helpful logs?

4

I believe the agent logs are in ~/.ccnet/logs, but I’ve not tried the appimage agent so it might be different. SeaDrive agent logs are in ~/.seadrive/logs.

1 Like
5

It’s also stored there for the appimage.
When trying to sync a library, I receive an issue that the SSL CA Cert could not be downloaded:

Summary 
[12/28/24 12:39:11] http-tx-mgr.c(800): libcurl failed to GET https://seafile.mydomain.de/seafhttp/protocol-version: Problem with the SSL CA cert (path? access rights?).
[12/28/24 12:39:11] clone-mgr.c(716): Transition clone state for <someHash> from [check server] to [error]: Failed to establish secure connection. Please check server SSL certificate

Is it correct that the
seafile-caddy/certificates/acme-v02.api.letsencrypt.org-directory/seafile.mydomain.de
folder and all of the files are owned by root?

Summary 
3 -rw------- 1 root root  2844 Dec  9 15:56 seafile.mydomain.de.crt
1 -rw------- 1 root root   512 Dec 28 09:50 seafile.mydomain.de.json
1 -rw-rw---- 1 root myUser  227 Dec  9 15:56 seafile.mydomain.de.key
6

I haven’t used caddy, but I believe that is correct. The default seafile docker setup seems to use root for everything (part of why I have been so active on the forums recently has been my efforts to fix this). Also I suspect that if that weren’t right, you would get the same certificate errors when going to seafile in your browser.

It might be worth verifying by going to https://seafile.mydomain.de/seafhttp/protocol-version in your browser in private or incognito most to verify it doesn’t complain about the certificate. Some browsers don’t use the system’s root CA cert list to verify (they have their own copy), so it might also be a good idea to check with the openssl command, which would look like this:

cat /dev/null | openssl s_client -connect seafile.mydomain.de:443 -servername seafile.mydomain.de -showcerts

Mostly the first few lines are most important. If your certificate isn’t accepted and trusted it will have an error like this:

verify error:num=19:self signed certificate in certificate chain
verify return:0

If it’s good, it will look like:

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R11
verify return:1
depth=0 CN = *.mydomain.de
verify return:1

And if your site is exposed to the internet, you can test it at sll labs at SSL Server Test (Powered by Qualys SSL Labs)

Basically if other programs on your machine accept your cert and the seafile agent doesn’t, I would strongly suspect a bug in the agent. There’s a set of trusted CA certs installed on your machine that most or all programs should share (some browser’s don’t trust you to maintain this properly and so they use their own set instead). They are used to verify that your certificate was signed by a trusted cert (or signed by cert that was signed by a trusted cert). If the AppImage isn’t using them right, or is just using its own outdated set, I would call that a bug.

1 Like
7

Thank you for all the help!
It seems indeed that the server cert seems fine from the checks:

Checks output 
https://seafile.mydomain.de/seafhttp/protocol-version
Response:
{"version": 2}


cat /dev/null | openssl s_client -connect seafile.mydomain.de:443 -servername seafile.mydomain.de -showcerts
Response:
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E5
verify return:1
depth=0 CN=seafile.mydomain.de
verify return:1

What I’m wondering about: How can it be that no one else encountered this so far?
Makes me a little bit skeptical whether it is really a problem with the client and not with my setup.

I’ll submit an issue on Github.

8

That is a good question, especially if your quoted output is correct. My seafile also has a Let’s Encrypt cert, and I installed the AppImage agent in a VM to test it, and it worked for me there. Maybe the AppImage version only has a problem on certain distributions? It worked fine in my VM on Debian 12.

1 Like
9

Ok, I have fixed it and I am very sorry!
In the server firewall, I had a number flip with the 443 rule.
I saw it before my last post, but it seems that the client needed to clear some cache before it worked again (also a restart didn’t help).

What’s surprises me is that it had worked with the missing rule in the browser and on the windows client… well

Thank you again @tomservo

10

I’m gad you got it fixed, even if I wasn’t much help. I had concluded that there couldn’t be anything at the server end. I guess it’s true that computers express their creativity in the ways they choose cause problems. :slight_smile: