latest image causes bad request

[hasufell]

contradictory scheme handlers

Doesn't happen with 6.2.5.

[shoeper]

I cannot reproduce the issue.

[falkzilm]

I have the same problem and trying to solve this.
I think it has something to do with proxy settings and seafile docker settings, in my env i have a nginx proxy which delegates requests to docker images and maintain letsencrypt certs.

I configured it to use always HTTPS for the outside so if i open the page in browser it will always be https. But internaly he delegates maybe with HTTP and i think this causes with HTTP/2.0 some problems - i am trying to find a way to solve this out..

/EDIT
I couldnt figure it out properly so i rolled back to version 6.2.5

[oexar]

same problem here with the same configuration as falkzilm (seafile behind nginx-proxy)

[shoeper]

Have you checked the logs?
Execute bash within the container and check /var/log/nginx/* and /opt/seafile/logs/*

[oexar]

I've checked both directories and no trace of the problem.

So far my solution is to comment "proxy_set_header X-Forwarded-Proto $scheme;" out in /templates/seafile.nginx.conf.template

[shoeper]

So the issue is obvious.

Your proxy sets X-Forwarded-Proto https and the nginx proxy within the image sets another one to X-Forwarded-Proto http. Now you the two are contradictory.

[hasufell]

@shoeper The issue may be obvious, but not the proper solution. It appears this image doesn't give any control over the internal nginx configuration and doesn't account for the most common setup which is people running jwilder/nginx-proxy.

[mplorentz]

I am having the same issue, same setup. @yopbot's workaround fixes the issue for me. I'm happy to attempt a PR if we know what the fix should be.

[crystalnet]

+1
just ran into the same issue. a fix would be much appreciated 😃 👍 🙏

[realies]

it is still an issue

[orangelynx]

Also the bad request says "Contradictory scheme headers" (not handlers, at least for me, for people googling the issue).

In general the docker image leaves much to be desired, if anyone has an alternative option, I'd appreciate a pointer.

[windsource]

I use sunx/seafile with SQLite and an external nginx proxy. That works quite OK.

[melyux]

Still no solution to this? Perhaps the nginx process should be further stripped away from the Seafile like the database and memcached.

Even after patching the template file, I get "Page unavailable due to a server hiccup".

[Redsandro]

@renfeipeng did you close this in favor of #167? I would like to make two suggestions for future issues:

1. Close the newer issue as duplicate, not the older issue. Older issues already collected some knowledge and speculation, and rank higher in google search results. You can change the title.
2. Please comment why you closed an issue. When coming from google, people don't know about Use $proxy_add_x_forwarded_for in nginx template for X-Forwarded-For header #167 and closing issues without a comment or addressing the issue comes across as a bit ignorant, even though you're just doing some maintenance.

---

Many people use reverse proxies so they can host multiple services on a single VPS.

Here is how I got seafile-docker 7.0.4 working with nginx-proxy:

Copy seafile.nginx.conf.template to the directory where you placed docker-compose.yml.

Edit seafile.nginx.conf.template:

   server_name {{ domain }};

-  client_max_body_size 10m;
+  client_max_body_size 0;

   location / {
       proxy_pass http://127.0.0.1:8000/;
       proxy_read_timeout 310s;
       proxy_set_header Host $host;
-      proxy_set_header Forwarded "for=$remote_addr;proto=$scheme";
+      proxy_set_header Forwarded "for=$proxy_add_x_forwarded_for;proto=$http_x_forwarded_proto";
-      proxy_set_header X-Forwarded-For $remote_addr;
+      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-      proxy_set_header X-Forwarded-Proto $scheme;
+      proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
-      proxy_set_header X-Real-IP $remote_addr;
+      proxy_set_header X-Real-IP $proxy_add_x_forwarded_for;
       proxy_set_header Connection "";
       proxy_http_version 1.1;
   }

(The change to client_max_body_size is necessary if you want to be able to sync files larger than 10 MB.)

Change your docker-compose.yml like so:

  seafile:
    image: seafileltd/seafile-mc:latest
    container_name: seafile
- ports:
-   - "80:80"
-#  - "443:443"  # If https is enabled, cancel the comment.
+ expose:
+  - 80
    volumes:
      - /opt/seafile-data:/shared   # Requested, specifies the path to Seafile data persistent store.
+     - ./seafile.nginx.conf.template:/templates/seafile.nginx.conf.template:ro
    environment:
+     VIRTUAL_HOST: seafile.example.test
+     VIRTUAL_PORT: 80
+     LETSENCRYPT_HOST: seafile.example.test
+     LETSENCRYPT_EMAIL: [email protected]

---

The minimal necessary steps to satisfy nginx-proxy users would be to change the headers in the nginx template. For illustrative purposes, I copy them from above:

-        proxy_set_header Forwarded "for=$remote_addr;proto=$scheme";
+        proxy_set_header Forwarded "for=$proxy_add_x_forwarded_for;proto=$http_x_forwarded_proto";
-        proxy_set_header X-Forwarded-For $remote_addr;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-        proxy_set_header X-Forwarded-Proto $scheme;
+        proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
-        proxy_set_header X-Real-IP $remote_addr;
+        proxy_set_header X-Real-IP $proxy_add_x_forwarded_for;

However, to make seafile-docker work without nginx-proxy, someone simply needs to add some checks to the template:

if [the proxy headers exist]:
    use them
else:
    use current template values

Otherwise variables like $http_x_forwarded_proto and $proxy_add_x_forwarded_for might just be empty, causing the non-proxy container not to work.

[renfeipeng]

Thank you for your suggestion, I think what you said is very reasonable.

[icpz]

@Redsandro
The nginx variable $proxy_add_x_forwarded_for won't be empty. If the xff header is not set by the reverse proxy, this var will be equal to $remote_addr. So the if is not needed.

BTW I think the X-Real-IP header should keep "real ip".

[Redsandro]

@lcdtyph

The nginx variable $proxy_add_x_forwarded_for won't be empty. If the xff header is not set by the reverse proxy, this var will be equal to $remote_addr. So the if is not needed.

Great! 👍

I thought I read that, but wasn't sure. Just mentioned 'might be empty' so no mistakes will be made.

BTW I think the X-Real-IP header should keep "real ip".

I'm not sure what you mean. The X-Real-IP should be the real internet-facing customer IP. So we need an if, right?

if (X-Real-IP exists): Keep X-Real-IP
else: Use $remote_addr.

In my example I'm using $proxy_add_x_forwarded_for because it will always be the final ip address (in case of maximum 1 proxy, which is the case with nginx-proxy)

[cr1st1p]

I just added a pull request to improve the docker image #187, one fix being using it behind a SSL termination proxy (I'm using it inside a kubernetes cluster)

Suggestions:
a) for seafile behind an nginx as SSL termination proxy, like @falkzilm seem to have, with that PR, you would set environment variable BEHIND_SSL_TERMINATION and it will automatically set 'proto' to ssl and not $scheme
b) at first look, to me it looks like the nginx template and associated code should handle a new environment variable to let it know it is behind a proxy and instead of using
proxy_set_header X-Forwarded-For $remote_addr;`` it would use proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;```
Also, having BEHIND_SSL_TERMINATION enabled should automatically enable it.

Update: Looking at an nginx ingress controller setup I see more interesting stuff that could make it into the image + maybe different method of defining the nginx configuration lines.
I might try an update on the nginx config, but only if effort is worthwhile - that is, the mentioned pull request gets accepted.

[pbirkle]

Unfortunately I'm not able setting up seafile behind my nginx reverse proxy (nginx, jwilder/docker-gen and jrcs/letsencrypt-nginx-proxy-companion). Neither the workaround from @shoeper nor the workaround from @Redsandro are working for me.

Does anyone know if this repository is still maintained and if there are any plans in fixing the problem?

[cr1st1p]

@patrick-birkle I updated today my PR, added info on the environment variables used and also created a docker image at https://hub.docker.com/repository/docker/cr1st1p/seafile-server
You did not provide details about what is not working for you, but try that image. And I think you need to set BEHIND_SSL_TERMINATION=1

[saimonsez]

@Redsandro: Your comment helped me to make seafiles web-ui accessible behind an nginx-proxy. Thank you very much! However, clients are still unable to sync, I guess thats because of fastcgi. Will this be solved with your PR and do you have a workaround in the meantime?

What I can see in nginx-proxy logs is

[01/Mar/2020:12:07:16` +0000] "GET /seafhttp/protocol-version HTTP/1.1" 503 197 "-" "Seafile/7.0.4 (Windows NT)"

and nothing in seafile logs.

Clients display "waiting for sync" with a grey icon.

[Redsandro]

@saimonsez I'm not sure why it doesn't work for you. The clients connect over the same port, right? The web-ui address is the same address you enter into the client when connecting, right?

If the client connection doesn't work, but the web-ui connection does work, then I'm not sure why this is. Are you connecting to a different url?

Seafile did change from version 6 to 7 in the meantime. I'll post my updated files in case it helps you:

docker-compose.yml

Notice how the only port exposed is port 80. The nginx-proxy uses that internally to provide the TLS.

version: '3.5'

volumes:
    seaf-shared:
    seaf-db:

networks:
    seaf-net:
    nginx-proxy:
        external:
            name: nginx-proxy

services:
  db:
    image: mariadb:10.1
    container_name: seaf-db
    restart: always
    env_file:
      - seaf-db.env
    volumes:
      - seaf-db:/var/lib/mysql
    networks:
      - seaf-net

  memcached:
    image: memcached:1.5.6
    container_name: seaf-memcached
    restart: always
    entrypoint: memcached -m 256
    networks:
      - seaf-net

  seafile:
    image: seafileltd/seafile-mc:latest
    container_name: seaf-mc
    restart: always
    expose:
      - 80
    volumes:
      - seaf-shared:/shared
      - ./seafile.nginx.conf.template:/templates/seafile.nginx.conf.template:ro
    env_file:
      - seaf.env
    environment:
      DB_HOST: db
      VIRTUAL_HOST: [my-reverse-proxy-domain]
      VIRTUAL_PORT: 80
      LETSENCRYPT_HOST: [my-reverse-proxy-domain]
      LETSENCRYPT_EMAIL: [my-email-address]
    links:
      - db
      - memcached
    networks:
      - nginx-proxy
      - seaf-net

seafile.nginx.conf.template

# -*- mode: nginx -*-
# Auto generated at {{ current_timestr }}
{% if https -%}
server {
    listen 80;
    server_name _ default_server;
    rewrite ^ https://{{ domain }}$request_uri? permanent;
}
{% endif -%}

server {
{% if https -%}
    listen 443;
    ssl on;
    ssl_certificate      /shared/ssl/{{ domain }}.crt;
    ssl_certificate_key  /shared/ssl/{{ domain }}.key;

    ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;

    # TODO: More SSL security hardening: ssl_session_tickets & ssl_dhparam
    # ssl_session_tickets on;
    # ssl_session_ticket_key /etc/nginx/sessionticket.key;
    # ssl_session_cache shared:SSL:10m;
    # ssl_session_timeout 10m;
{% else -%}
    listen 80;
{% endif -%}

    server_name {{ domain }};

    client_max_body_size 0;

    location / {
        proxy_pass http://127.0.0.1:8000/;
        proxy_read_timeout 310s;
        proxy_set_header Host $host;
        proxy_set_header Forwarded "for=$proxy_add_x_forwarded_for;proto=$http_x_forwarded_proto";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
        proxy_set_header X-Real-IP $proxy_add_x_forwarded_for;
    }

    location /seafhttp {
        rewrite ^/seafhttp(.*)$ $1 break;
        proxy_pass http://127.0.0.1:8082;
        client_max_body_size 0;
        proxy_connect_timeout  36000s;
        proxy_read_timeout  36000s;
    }

    location /seafdav {
        client_max_body_size 0;
        fastcgi_pass    127.0.0.1:8080;
        fastcgi_param   SCRIPT_FILENAME     $document_root$fastcgi_script_name;
        fastcgi_param   PATH_INFO           $fastcgi_script_name;

        fastcgi_param   SERVER_PROTOCOL     $server_protocol;
        fastcgi_param   QUERY_STRING        $query_string;
        fastcgi_param   REQUEST_METHOD      $request_method;
        fastcgi_param   CONTENT_TYPE        $content_type;
        fastcgi_param   CONTENT_LENGTH      $content_length;
        fastcgi_param   SERVER_ADDR         $server_addr;
        fastcgi_param   SERVER_PORT         $server_port;
        fastcgi_param   SERVER_NAME         $server_name;

        access_log      /var/log/nginx/seafdav.access.log;
        error_log       /var/log/nginx/seafdav.error.log;
    }

    location /media {
        root /opt/seafile/seafile-server-latest/seahub;
    }

    # For letsencrypt
    location /.well-known/acme-challenge/ {
        alias /var/www/challenges/;
        try_files $uri =404;
    }
}

Will this be solved with your PR

I don't have an active PR, and I don't think anyone really cares about this issue. Otherwise it would have been addressed eons ago.

I mean, who in their right mind uses docker exclusively for a single service on their httpx ports? Everyone I know shares multiple docker services using a reverse proxy like nginx-proxy or traefik. It's just that no one uses Seafile.

[saimonsez]

@Redsandro, thanks for the update.

I adopted your seafile.nginx.conf.template and my docker-compose.yml is

version: '2.0'
services:
  db:
    image: mariadb:10.1
    container_name: seafile-mysql
    environment:
      - MYSQL_ROOT_PASSWORD=
    volumes:
      - .db:/var/lib/mysql

  memcached:
    image: memcached:1.5.6
    container_name: seafile-memcached
    entrypoint: memcached -m 256

  seafile:
    image: seafileltd/seafile-mc:latest
    container_name: seafile
    expose:
      - 80
    volumes:
      - ./data:/shared
      - ./seafile.nginx.conf.template:/templates/seafile.nginx.conf.template:ro
    environment:
      - DB_HOST=db
      - DB_ROOT_PASSWD=
      - TIME_ZONE=Europe/Zurich
      - SEAFILE_ADMIN_EMAIL=
      - SEAFILE_ADMIN_PASSWORD=
      - VIRTUAL_HOST=seafile.domain.com
      - VIRTUAL_NETWORK=nginx-proxy
      - VIRTUAL_PORT=80
      - LETSENCRYPT_HOST=seafile.domain.com
      - [email protected]
    depends_on:
      - db
      - memcached
networks:
  default:
    external:
      name: nginx-proxy

and docker-compose.yml of nginx-proxy

version: '2'

services:

  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./conf:/etc/nginx/conf.d
      - ./vhost:/etc/nginx/vhost.d
      - ./html:/usr/share/nginx/html
      - ./dhparam:/etc/nginx/dhparam
      - ./certs:/etc/nginx/certs:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro
    restart: always

  letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: nginx-proxy-le
    depends_on:
      - nginx-proxy
    volumes_from:
      - nginx-proxy
    volumes:
      - ./certs:/etc/nginx/certs
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: always

networks:
  default:
    external:
      name: nginx-proxy

Thats not exaclty as yours but should fit. Still, clients can not sync.

Do you use any other env variables or special nginx config of jwilder/proxy?

[Redsandro]

@saimonsez You need to add SEAFILE_SERVER_LETSENCRYPT=false to your seafile environment (because nginx-proxy takes care of that), and possibly remove VIRTUAL_NETWORK. I've never used that and it seems irrelevant in this config, since it's configured as the default for all related containers. maybe leave it in, because I manually set up the extra containers.

[pbirkle]

@cr1st1p sorry for my late reply, thank's for your answer and effort in providing your image. It worked good with your image. After a few days I was still not fully happy with this solution, so I started investigating a bit more.

I now found out, that since docker image version 7.0.11 the workaround from @Redsandro (changing the proxy_headers) is not working anymore. If I have more time in the next few days I will try to investigate which changes were made from version 7.0.10 to 7.0.11. Unfortunately I couldn't find any conspicuous changes while skimming the changelog.

[Redsandro]

@patrick-birkle so it stopped working in 7.0.11? Thanks for the heads up! I'll make sure not to update my container!

[pbirkle]

Right, I'm currently running seafile 7.0.10 docker image without problems. When changing to the 7.0.11 image I get the Contradictory scheme headers message. I will provide more information as soon as I'm able to test the newer versions.

[Redsandro]

This might also explain why @saimonsez couldn't get it to work.

[saimonsez]

I will check that on saturday if I find some time.

[saimonsez]

The latest seafile-mc is 5 months old and the version is 7.0.5: https://hub.docker.com/r/seafileltd/seafile-mc/tags. What image are you using?

[pbirkle]

Sorry for the missunderstanding. Since I'm hosting seafile only for 2 users I'm currently using the seafile-pro-mc image (pro version is free up to 3 users). You can get pro images from their own image repository. You can find further information about it here.

To be honest, until now I didn't know that the image for the community edition is only available until version 7.0.5. Sorry for that.

[shoeper]

The latest seafile-mc is 5 months old and the version is 7.0.5: https://hub.docker.com/r/seafileltd/seafile-mc/tags. What image are you using?

This is the latest stable CE release. Pro and CE versions do not necessarily match.

[saimonsez]

Now I am completely confused. To narrow down the problem, I created another seafile instance running on https://temp.domain.com. So, no configuration leftovers or anything else - just a fresh installation from scratch. The docker-compose.yml looks like this:

version: '3'
services:
  seafile-temp-mariadb:
    image: mariadb:10.1
    container_name: seafile-temp-mariadb
    environment:
      - MYSQL_ROOT_PASSWORD=password
      - MYSQL_LOG_CONSOLE=true
    volumes:
      - ./db:/var/lib/mysql
    networks:
      - seafile-net

  seafile-temp-memcached:
    image: memcached:1.5.6
    container_name: seafile-temp-memcached
    entrypoint: memcached -m 256
    networks:
      - seafile-net

  seafile-temp:
    image: seafileltd/seafile-mc:latest
    container_name: seafile-temp
    expose:
      - 80
    volumes:
      - ./data:/shared
      - ./seafile.nginx.conf.template:/templates/seafile.nginx.conf.template:ro
    environment:
      - DB_HOST=seafile-temp-mariadb
      - DB_ROOT_PASSWD=password
      - TIME_ZONE=Europe/Zurich
      - [email protected]
      - SEAFILE_ADMIN_PASSWORD=pasword
      - SEAFILE_SERVER_LETSENCRYPT=false
      - VIRTUAL_HOST=temp.domain.com
#      - VIRTUAL_NETWORK=nginx-proxy
#      - VIRTUAL_PORT=80
      - LETSENCRYPT_HOST=temp.domain.com
      - [email protected]
    depends_on:
      - seafile-temp-mariadb
      - seafile-temp-memcached
    networks:
      - seafile-net
      - nginx-proxy
networks:
  seafile-net:
  nginx-proxy:
    external:
      name: nginx-proxy

I decided to match my configuration with the one from @Redsandro regarding the networks. seafile.nginx.conf.template and docker-compose.yml of nginx-proxy are still the same.

The result is extremely unstable, as I am getting constantly

Page unavailable
Sorry, but the requested page is unavailable due to a server hiccup.
Our engineers have been notified, so check back later.

Sometimes, the login page gets loaded, but I cannot login.

[Redsandro]

@saimonsez I also have SEAFILE_SERVER_HOSTNAME=temp.domain.com. Apart from that, it looks identical.

mariadb:10.1
memcached:1.5.6
seafileltd/seafile-mc:7.0.4

I'm using jwilder/docker-gen and jrcs/letsencrypt-nginx-proxy-companion for reverse proxy.

[pbirkle]

@saimonsez Coincidentally I ran into the same issue a few moments ago

Page unavailable
Sorry, but the requested page is unavailable due to a server hiccup.
Our engineers have been notified, so check back later.

For me the problem always appears when I'm trying to login only with my username and not my email address. Have you tried logging in with your email or with your username?

[saimonsez]

It's working now. That 'Page unavailable' error occured because of memcached not being reachable which was caused by #196. Overall it took me a couple of days to migrate to seafile-docker and put it behind a nginx-proxy, just because this image seems to ignore multiple docker conventions and best practices.

edit: Android clients still fail to auto-upload photos ('upload failed'). Could someone with a working reverse-proxy setup verify this?

[saimonsez]

Could this please be labeled as a bug and not as a question. At the current state, seafile-docker only works partialy behind nginx-proxy. Some of my Libraries fail to sync and as mentioned, auto-upload of photos does not work at all. Using seafile-docker without a proxy, I do not have these problems.

My guess is, that #187 could solve this.

[flukejones]

auto-upload of photos does not work at all

Confirming. I switched from nextcloud to seafile using most of my previous nginx proxy (forces ssl) and have the same issue.

[dgleba]

I struggled to setup a fresh empty seafile-mc 7.0.5 using jwilder nginx-proxy with letsencrypt companion.
I was getting bad gateway errors.

I implemented the answer here:
https://stackoverflow.com/a/60474891/2744870
It allowed the web interface to work, but not sync.

I added the config I previously used with docker seafile server 6.2.5 and now it syncs.

The config is at: https://github.com/dgleba/proxy457/blob/master/vol/nginx/vhost.d/sf3.dg.jgleba.com
This is it here as well.

#
# for seafile.  ./vol/nginx/vhost.d/sf3.dg.jgleba.com
#
  location /seafhttp {
      rewrite ^/seafhttp(.*)$ $1 break;
      proxy_pass http://seafile3:8082;
      client_max_body_size 0;
      proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_connect_timeout  36000s;
      proxy_read_timeout  36000s;
      proxy_send_timeout  36000s;
      send_timeout  36000s;
  }

The repo is what I am using. See the seafile3 service in https://github.com/dgleba/proxy457/blob/master/docker-compose.yml

I am not sure what I did was good practice.

Further investigation is needed, but it is working right now.

[k997]

I modify /shared/nginx/conf/seafile.nginx.conf in seafile-mc:7.1.4 and find it can work very well.

seafile:
    image: seafileltd/seafile-mc:7.1.4
    container_name: seafile
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - /www/seafile/data:/shared 
      - ./seafile.nginx.conf:/shared/nginx/conf/seafile.nginx.conf
    environment:
      - DB_HOST=db
      - DB_ROOT_PASSWD=mysql_password

      - [email protected] 
      - SEAFILE_ADMIN_PASSWORD=asecret 

      - VIRTUAL_HOST=example.domain.com
      - LETSENCRYPT_HOST=example.domain.com
      - [email protected]
    networks:
      - seafile-net
      - nginx-proxy

The seafile.nginx.conf

# -*- mode: nginx -*-
server {
listen 80;
server_name seafile.example.com;

    client_max_body_size 10m;

    location / {
        proxy_pass http://127.0.0.1:8000/;
        proxy_read_timeout 310s;
        proxy_set_header Host $host;
        proxy_set_header Forwarded "for=$proxy_add_x_forwarded_for;proto=$http_x_forwarded_proto";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
        proxy_set_header X-Real-IP $proxy_add_x_forwarded_for;

        proxy_set_header Connection "";
        proxy_http_version 1.1;

        client_max_body_size 0;
        access_log      /var/log/nginx/seahub.access.log seafileformat;
        error_log       /var/log/nginx/seahub.error.log;
    }
    
        location /seafhttp {
        rewrite ^/seafhttp(.*)$ $1 break;
        proxy_pass http://127.0.0.1:8082;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        client_max_body_size 0;
        proxy_connect_timeout  36000s;
        proxy_read_timeout  36000s;
        proxy_request_buffering off;
        access_log      /var/log/nginx/seafhttp.access.log seafileformat;
        error_log       /var/log/nginx/seafhttp.error.log;
    }   
        location /seafdav {
        proxy_pass         http://127.0.0.1:8080;
        proxy_set_header   Host $host;

        proxy_set_header   X-Real-IP $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Host $server_name;

        proxy_set_header   X-Forwarded-Proto $http_x_forwarded_proto;
        proxy_read_timeout  1200s;
        client_max_body_size 0;

        access_log      /var/log/nginx/seafdav.access.log seafileformat;
        error_log       /var/log/nginx/seafdav.error.log;
    }

        location /media {
            root /opt/seafile/seafile-server-latest/seahub;
        }

        # For letsencrypt
        location /.well-known/acme-challenge/ {
            alias /var/www/challenges/;
            try_files $uri =404;
        }
}

[tho7o]

@k997 Work!

[homehoster]

Hey guys!

I got a solution for the network problems the problem by jwilder is the client_max_body_size. There's no setting so the max upload ist 1M.

I solved it by a new file and a new line in docker-compose.yml at the proxy-container. Look here for a complete explaination:

https://github.com/strahli30/HowTo-use-Docker-Seafile-Plex-NGINX

In short:

• Create a new folder mkdir nginx.template

• Create a new file sudo nano nginx.template/client_max_body_size.conf

• One line in this file: client_max_body_size 0;

• in the docker-compose.yml of jwilder/nginx-proxy:alpine at volumes this line:
  ./nginx.template/client_max_body_size.conf:/etc/nginx/conf.d/client_max_body_size.conf:ro

After restart of Seafile and Nginx all works fine! :-)

[tdworz]

As of version 10.0.0, the solution originally posted by @Redsandro still works. @k997's solution also works.

The difference between @Redsandro's solution and @k997's solution is that @Redsandro proposes editing the template file which is used to generate an Nginx config file (/templates/seafile.nginx.conf.template), while @k997 proposes editing the generated Nginx config (/shared/nginx/conf/seafile.nginx.conf) directly.

One thing to know if you are using @Redsandro's solution (and maybe why many here are struggling and eventually finding success with @k997's solution) is that the config file generation seems to only happen once, when the container's file system is first created. Running docker compose down followed by docker compose up deletes and creates new containers, but if you are not explicitly deleting the contents of the mounted directory or the mounted volume (using docker volume rm <volume name>), the configuration re-generation step does not seem to happen.

[freeplant]

I will close the issue. New thread with proper title can be opened if more discussions are needed.