I’m a bit at my wits’ end, I had a preexisting instance working but had to recover from backups. It turns out the backups were incomplete, so I’m having to rebuild the configs. I’m using the SWAG Nginx reverse proxy docker container on a separate machine from the VM hosting my seafile instance (which I’ve upgraded to v10).
According to the docs, I should be able to run the reverse proxy and forward requests to the ports on the Seafile VM:
## Version 2022/09/08
# make sure that your dns has a cname set for <container_name> and that your <container_name> container is not using a base url
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name seafile.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
# enable for Authelia (requires authelia-location.conf in the location block)
include /config/nginx/authelia-server.conf;
location / {
# enable for Authelia (requires authelia-server.conf in the server block)
include /config/nginx/authelia-location.conf;
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
proxy_pass http://seafile:8000;
}
location /seafhttp {
rewrite ^/seafhttp(.*)$ $1 break;
proxy_pass http://seafile: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 36000;
send_timeout 36000;
}
}
This way the SWAG container can handle all of the reverse proxy tasks. Alternatively (prior to my system recovery I used this) I can have a very simple proxy conf on the SWAG container and use the HTTP reverse proxy on the seafile VM. With this setup this is the proxy.conf:
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name seafile.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
# enable for Authelia (requires authelia-location.conf in the location block)
include /config/nginx/authelia-server.conf;
location / {
# enable for Authelia (requires authelia-server.conf in the server block)
include /config/nginx/authelia-location.conf;
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
proxy_pass http://seafile:80;
}
}
And this is the seafile.conf on the seafile VM:
log_format seafileformat '$http_x_forwarded_for $remote_addr [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_response_time';
server {
listen 80;
server_name seafile.pcwilcox.com;
# Prevents the NGINX version from being displayed in the HTTP response header
server_tokens off;
proxy_set_header X-Forwarded-For $remote_addr;
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_read_timeout 1200s;
proxy_set_header X-Forwarded-Proto https;
# Used to view/edit office file via Office Online Server
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;
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;
access_log /var/log/nginx/seafhttp.access.log seafileformat;
error_log /var/log/nginx/seafhttp.error.log;
}
location /media {
root /opt/seafile/seafile-server-latest/seahub;
}
}
In either case literally zero clients are able to login, with no real clear indication of why. Mostly my logs are full of stuff like this:
==> /opt/seafile/logs/seafile.log <==
2023-03-20 19:07:50 start to serve on pipe client
2023-03-20 19:08:39 start to serve on pipe client
2023-03-20 19:09:02 start to serve on pipe client
2023-03-20 19:09:03 start to serve on pipe client
2023-03-20 19:09:18 start to serve on pipe client
2023-03-20 19:14:52 start to serve on pipe client
2023-03-20 19:22:11 start to serve on pipe client
2023-03-20 19:23:07 start to serve on pipe client
2023-03-20 19:23:55 start to serve on pipe client
2023-03-20 19:24:00 start to serve on pipe client
==> /opt/seafile/logs/seahub.log <==
2023-03-20 19:23:02,530 [WARNING] django.request:224 log_response Forbidden: /api2/account/info/
2023-03-20 19:23:07,478 [WARNING] django.request:224 log_response Forbidden: /api2/account/info/
2023-03-20 19:23:09,920 [WARNING] django.request:224 log_response Forbidden: /api2/repos/
2023-03-20 19:23:22,036 [WARNING] django.request:224 log_response Forbidden: /api2/account/info/
2023-03-20 19:23:39,886 [WARNING] django.request:224 log_response Forbidden: /api2/repos/
2023-03-20 19:23:55,847 [WARNING] django.request:224 log_response Forbidden: /api2/account/info/
2023-03-20 19:24:01,025 [WARNING] django.request:224 log_response Forbidden: /api2/account/info/
2023-03-20 19:24:09,599 [WARNING] django.request:224 log_response Forbidden: /api2/repos/
2023-03-20 19:24:22,067 [WARNING] django.request:224 log_response Forbidden: /api2/account/info/
2023-03-20 19:24:39,617 [WARNING] django.request:224 log_response Forbidden: /api2/repos/
I see elsewhere in the forum and in the github issue trackers that this django activity is meaningless but honestly I find that hard to believe, given that it’s like clockwork - I click ‘login’ on any client and this is the only log activity that occurs.
Anyways in my ccnet.conf I have configured SERVICE_URL=https://seafile.mydomain.com, gunicorn.conf.py has bind = "0.0.0.0:8000", seafile.conf has host = 0.0.0.0 and port = 8082 under [fileserver], and service URL etc are set in seahub_settings.py also.
Surely there must be some config step I’ve missed, but I can’t for the life of me find it. Is anyone familiar and able to help?