Install from scratch tries to connect to port 8000 also only 80/443 are exposed

[tehXor]

In https://download.seafile.com/published/support/docker/deploy%20seafile%20with%20docker.md it says run docker-compose up -d, wait a little and connect to your domain.

Now I'm really not new to docker and run a lot of dockerized services typically behind a nginx SSL proxy and load balancer. However, with this docker compose package I fail and currently am wondering if I maybe am somewhat dens 😵

So when I do docker-compose up -d (obviously after configuring docker-compose.yml) I get a wonderful web GUI to which I can connect but as I try to do anything file related I get network errors. A glance in the console shows failing connection attempts to https://mydomain.de:8000/... en mass. That is no wonder since the https://download.seafile.com/d/d7c8da31bf9f47db938e/files/?p=/docker/docker-compose.yml does not expose such a port 8000 to the public! Looking at docker ps it also looks like none of the underlying images would expose such a port internally.

So why is a blank docker-compose up -d from the latest images and with the latest docker-compose.yml even trying to connect to such a port? I also couldn't find docs regarding this matter. Only for the non-docker version but here it's clearly stated that Port 8000 shouldn't be exposed public and instead routed to via a nginx proxy. So I would guess (since only 80/443 are configured) the docker compose package already does this and I only have to forward to itd 80/443?

If not and in general, from point blank when I docker-compose up -d, how do I have to configure an independent nginx SSL proxy before it and maybe adjust the docker-compose.yml?

Typically this would involve telling the service (seafile in this case) that it already is behind https also the proxy before connects via proxy_pass http://... and stating HTTP_FORWARDED_COUNT=n (n depending on the proxies before the service). However here it seems to be a bit more. Next to the port 8000 problem it also seems /media would have to be treated differently...

I'd appreciate any info regarding this matter. And even if I am stupid right now, maybe adding the info in way that one actually can run docker-compose up -d and has working default setup with all basic information in https://download.seafile.com/published/support/docker/deploy%20seafile%20with%20docker.md would be nice 😊

[tehXor]

Meanwhile I got it running with an additional port configuration in the docker-compose.yml: - "8082:8082". And then the SSL terminating nginx proxy has to proxy_pass http://internal-seafile-domain:8082; for location /seafhttp and proxy_pass http://internal-seafile-domain; for location /. Finally I had to remove all occurrences of Port 8000 manually in the default config.

I couldn't find this documented or in the docker-compose examples. Also port 8082 doesn't seem to be exposed?

I still haven't found a way to tell seafile the HTTP_FORWARDED_COUNT=3 so everybody shows up with the IP of the last internal proxy. But maybe I'm missing something since I would guess every setup beyond S(mallest)OHO will have at least 1 proxy in its chain?

Besides, what is called "multi container" docker setup also seems very strange to say the least. Why would someone stuff an apache or nginx service in an container for another service when it is intended as "multi container"? And even worse (or I was hallucinating) why the heck is there an ssh daemon running in a container? 😨 You wouldn't even need it for development purposes (there are things like docker exec -it etc) but for sure not in production!

So I gotta say, this all looks like a mess!

But after saying this, it also looks like Seafile is still doing things well when it comes down to its basic and main task which would be file syncing. Even compared to the most recent NextCloud/OwnCloud versions.

So I really hope what I've struggled with above are no signs of a dying project and seafile manages to stay up to date and compete with other solutions.

[tehXor]

Have the issues been resolved?

[renfeipeng]

This is not a bug. We have configured nginx as a reverse proxy in docker, all requests are processed via port 80 or 443. The problem with your inability to upload or download files is because the correct SERVICE_URL and FILE_SERVER_ROOT are not set. Should be set toSERVICE_URL=http://example.seafile.com FILE_SERVER_ROOT=http://example.seafile.com/seafhttp or SERVICE_URL=https://example.seafile.com FILE_SERVER_ROOT=https://example.seafile.com/seafhttp

[tehXor]

Yes, that's what I figured out the hard way as well.

But a new docker (compose) based installation will connect to 8000. So when you say This is not a bug. I'd say at least a serious issue and it either should get fixed or well documented.

Not to mention all the other issues I came across. But I also wouldn't know where to start, the documentation which is lacking information and also is all over the place (why is there for instance https://download.seafile.com/published/support and https://manual.seafile.com/ ? which should users pick?). Or the docker setup itself which is far from standard "compose-able" setups (see some notes in my second post) which makes it additionally problematic when not documented...

[renfeipeng]

The latest reference documentation is: https://download.seafile.com/published/support

[seoester]

I just spent two hours debugging the same issue.

Please consider re-opening this issue until the problem is solved.

[seoester]

SERVICE_URL should be set to the correct value while bootstrapping the configuration within the docker container.

And until the release, this should be added to the documentation, so that users know that manual intervention is required to get Seafile working.

Thanks :)