Unable to upload from web gui on Seafile Server 13

Seafile Server Docker
, ,
1

Hey there!

I know I know…I’ve seem quite a few posts about this, but they seem to be different versions or the problem was originated somewhere else.

I have an opnsense firewall which runs caddy. Internal server where seafile is running.

What I’ve tried?

  • .env protocol changes to https (which breaks the whole thing) and http (which is the way it “should” work.
  • SERVICE_URL and FILE_SERVER_ROOT (deprecated on v13…it seems)
  • caddy setup to allow and reverse proxy the 8082 requests apart
  • docker with and without the “pre” setup caddy. At the end I just left the default docker container out of the equation not to have tw layers of proxying.
  • try catching dummy files…no errors.

this is the current caddy setup, of course I’ve tried the most simple setups, up to this:

cloud.example.org {
	encode gzip

	# File server
	@seafhttp path /seafhttp/*
	handle @seafhttp {
		reverse_proxy 192.168.30.30:8082 {
			# Headers
			header_up Host {host}
			header_up X-Real-IP {remote_host}
			header_up Connection ""
		}

		request_body {
			max_size 0
		}
	}

	# Web GUI
	handle {
		reverse_proxy 192.168.30.30:8587
	}
}

The .env:

#################################
#      Startup parameters       #
#################################
SEAFILE_SERVER_HOSTNAME=cloud.example.org
SEAFILE_SERVER_PROTOCOL=http

seahub_settings.py:

# For security consideration, please set to match the host/domain of your site, e.g., ALLOWED_HOSTS = ['.example.com'].
ALLOWED_HOSTS = ['.example.org']

# Whether to use a secure cookie for the CSRF cookie
CSRF_COOKIE_SECURE = True
CSRF_COOKIE_SAMESITE = 'Strict'

# Make sure Seafile generates HTTPS links externally
CSRF_TRUSTED_ORIGINS = ['https://cloud.example.org']

the uploads fail silently, I haven’t been able to find anything suspicious on the logs (neither docker’s or the seahub logs). I tried a dummy.123 file to try to catch it and I got this:

~/data/seafile$ sudo grep -r dummy.123 .

./opt/seafile-data/seafile/logs/seahub.access.log.2025-10-29:192.168.1.27 192.168.30.99 [29/Oct/2025:19:33:49 -0500] "GET /api/v2.1/repos/04d0b21d-480d-40b6-bd5f-423489c379e2/file-uploaded-bytes/?parent_dir=%2F&file_name=dummy.123 HTTP/1.1" 200 19 "https://cloud.example.org/library/04d0b21d-480d-40b6-bd5f-423489c379e2/Documents/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:144.0) Gecko/20100101 Firefox/144.0" 0.016

No errors on any logs.

I’m positive this is something really dumb from my side, but afters hours of trying….I need help. If there’s any additional information that might help, just let me know.

I really appreciate any help. Thanks in advance!!!

2

The seafile-server container includes a built-in Nginx that consolidates various components into a single port 80.

Your Caddy server should only forward requests to the port 80 of the seafile-server container, as the internal structure of the seafile-server is concealed from external access.

3

@daniel.pan thanks for your reply. Actually that’s how I started, the other stuff is just things I’ve tried trying to making it work:

	# Web GUI
	handle {
		reverse_proxy 192.168.30.30:8587
	}

that port 8587 is exposed from the docker and redirected internally to port 80.

seafile                   0.0.0.0:8082->8082/tcp, [::]:8082->8082/tcp, 0.0.0.0:8587->80/tcp, [::]:8587->80/tcp
seadoc                    80/tcp
seafile-notification      
seafile-mysql             3306/tcp
seafile-redis             6379/tcp

I know it must be something small, if you have any further ideas, I’m listening!

4

Can you check the browser console to see what error you have when uploading a file?

5

this is what appears on the firefox console:

Blocked loading mixed active content “http://cloud.example.org/seafhttp/upload-aj/fc475841-8f34-4dba-bc4f-928c9537ef4c?ret-json=1” cloud.example.org

just in case, this is from brave:

commons.ab06bad5.c3e63e59a54d.js:2 Mixed Content: The page at 'https://cloud.example.org/library/04d0b21d-480d-40b6-bd5f-423489c379e2/Documents/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://cloud.example.org/seafhttp/upload-aj/6e1a8d3c-d9c0-4172-94d3-cb4c11be1c80?ret-json=1'. This request has been blocked; the content must be served over HTTPS.
o.send	@	commons.ab06bad5.c3e63e59a54d.js:2
6

You should set SEAFILE_SERVER_PROTOCOL to https if you use HTTPS.

7

just to be clear (from my side). I have caddy which manages TLS and https, and its reverse proxying to the seafile server with http. That’s, according to my understanding the desired setup (right?). So, if I enable https as seafile’s protocol, should I bypass the certificate verification from caddy? or should I modify something else on the setup files in order to work in this current scheme?

Sorry, I’m a bit lost here, all my other services work like that, caddy handles the https traffic and the services are configure on http and reverse fropxied from caddy.

8

SEAFILE_SERVER_PROTOCOL is the to let Seafile server know how you connect it via internet. So that it can return a correct upload link when you upload a file.

Set SEAFILE_SERVER_PROTOCOL to https only affect the behaviour of candy if you use the default caddy.yml file included in our document.

If you use your own caddy, SEAFILE_SERVER_PROTOCOL will have no effect on your own reverse proxy. It just let Seafile server know how you connect it via internet.

9

@daniel.pan thanks to you reply, I focused on getting it to work on https. At the end of the day I must say I don’t know for sure what actually worked, but it did. I changed the exposed port 8586:80 and 8587:443, set caddy to point to the xxxx:80 and it worked. Something I had previously (90% sure) I had donde befor,e but without changing the ports numbers. So my guess is that somewhere in between caddy and docker’s, something got “stuck”.

I know I know, it sounds trivial, to say the least, but it worked. Here’s my caddy setup, no funny setups, plain, simple, beautiful:

        @cloud host cloud.example.org
        handle @cloud {
                reverse_proxy 192.168.30.30:8586
        }

also, bonus tip. Becuase I’m using my own caddy instead of the seafile implementation, here’s the notification server caddy part:

        @notification {
                host cloud.example.org
                path /notification/*
        }

        handle @notification {
                uri strip_prefix /notification
                reverse_proxy 192.168.30.30:8083
        }

thanks for your reply! gave me a clear path.

Saludos!

NOTE: the notification part should go first, otherwise caddy would hit first the web proxy without ever getting into the notifications