I looked a bit around the forums and found a few topics that pertain exactly to that, running Seafile on a non-default port :80. I know one topic where it was suggested to add additional port forwardings to seafile-server.yml and modify hostname in .env file to reflect that new port:
seafile-server.yml:
seafile:
ports:
- "8015:80"
.env:
SEAFILE_SERVER_HOSTNAME=<IP Address>:8015
Now everything works as long as seafile is accessed at <IP Address>:8015, but doesn’t that defy the purpose of caddy reverse proxy container? At least when it comes to accessing seafile by port specified in caddy.yml. It becomes impossible actually, you cannot reach seafile by <IP Address>:<caddyport> anymore. Users are effectively directly accessing seafile-server container on another port on a host machine, <caddyport> being left open and unusable.
Another User found himself in very similar situation, but didn’t change .env SEAFILE_SERVER_HOSTNAME definition to reflect changed port, so seafile web interface accessed over <caddyport> worked and you could perform any administrative task as normal but downloading or uploading files was impossible since direct links to files were lacking that custom port. as seen in the bellow screenshot I copied over from that reply.
Additionally Seadoc doesn’t work in this setup, accessing <Ip Address>:8015/sdoc-server/ yields 404 error, most probably since caddy reverse proxy is being bypassed.
So my question is, how to robustly set up a non-default port seafile installation without being forced to effectively bypass reverse proxy?
you have the benefit of docker, you can isolate that instance of seafile easily, I think you have to do more research on your own, cause we dont know why you want that set up and what it achieves, Claude is your friend
Running on a port other than default http not only has merit of its own but also should be the very basic configuration option. What if I would like to use it for other purposes? There are other servers that use :80 by default, to test them I usually start by running them in completely stock configuration and then making my own changes along the way.
Speaking of which I setup a temporary default Seafile v12 installation and I am finally able to upload and download files, but Seadoc refuses to work. Visiting <IP Address>/sdoc-server returns 404, I had to copy a piece of config from this post by TechnicallyReal to get /sdoc-server to respond with “Welcome to sdoc-server. The current version is 1.0.5“. Which is weird since why on earth would nginx in seafile container have to respond to /sdoc-server requests when everything should go through caddy container and caddy is set up to forward /sdoc-server to whatever IP happens to be assigned to seadoc:
First, you should ensure sdoc-server is accessible through the browser. You can check this by visiting https://your-sdoc-server-domain/sdoc-server/ in your browser. If you see “Welcome to sdoc-server,” then sdoc-server is successfully accessible via the browser.
Secondly, you should verify that the sdoc-server can access the Seafile server through its external domain name. You can review the error logs in the sdoc-server.log and sdoc-access.log files located in the /opt/seadoc-data/logs/ folder.
Finally, modify the configuration provided earlier, ensuring that you do not modify any other configurations.
When using HTTPS, it is important to ensure that the CA is trusted by your Docker server.
Okay turns out I am beyond incompetent, I setup certain firewall rules to limit access to only local network and only after 20 hours of troubleshooting I managed to check my firewall rules for hit counts.
Thanks to NAT being used to facilitate podman port forwarding packets are being sent with changed source address and I didn’t foresee that when creating those firewall rules.
I believe on v12 sdoc-access.log is not enabled by default given this is the default nginx-sdoc.conf: