Use SERVICE_URL and FILE_SERVER_ROOT as relative URLs

Hi, I’ve been having this problem since I started using seafile as my home cloud solution. The URLs SERVICE_URL and FILE_SERVER_ROOT (specially the latter) don’t allow me to access the server direcly without going trough a port forward on my firewall, since all downloads are redirected using those urls.

Say the public DNS name of the firewall where the seafile server is behind is jorgito.net, the local name of the server that hosts the seafile server is seafile.lan, and you can access seafile.lan's port 443 via jorgito.net's port 443, with just a simple port forward.
That’s all great, if you are outside the network you can access the server via the url https://jorgito.net/, and if you have a machine in the same network you might want to access the server via https://seafile.net/ to reduce the load on the firewall (if the local network supports up to gigabit/10gigabit speeds for example).
The problem is, the moment you start to sync/download something, the client’s won’t use the local address, they’ll use the values of FILE_SERVER_ROOT and SERVICE_URL, and those are set to https://jorgito.net/seafhttp and https://jorgito.net/ respectively, because you want the server to be accesible from the outside. Now that becomes even worse when you have no way to enable NAT loopback on your firewall.

Is there a way to make those URLs relative to the one the client is already using? IMHO there should be no need to hardcode those, it’s just limiting what seafile can do.

Thanks for reading, have a nice day!

2 Likes

You could run an internal DNS server resolving the domain to your internal ip. Thus only one domain name is required, which has also the advantage that it works for mobile clients.

That would break my network layout, unless I also forward traffic to it to the firewall, which I am not willing to do unless, as I said, I wanted to break the layout.

I don’t think it would break your network layout and you wouldn’t need to forward the traffic to the firewall as well.

As I understood your setup is as follows:

Firewall e.g. 10.0.0.1 + external IP

Seafile Server e.g. 10.0.0.10

Now you resolve jorgito.net to your public IP, but use an internal DNS Server resolving jorgito.net to 10.0.0.10.

Yes it would break it. I need jorgito.net to be pointing to the public address of the firewall, else other services that are accesible trough it won’t work from the internal network.

Then you could use a subdomain.

Yeah, and at that point I could just route the traffic trough the firewall and not bother doing all of that. That’s not the point of the thread, I appreciate your help but I already thought trough this a while ago (I’ve been using seafile for more than two years now) and the best solution would be to allow relative urls on those variables. Seeing that’s impossible to do this without touching the code, some hints at what files/lines I need to modify would be great.

Ok, I’ve moved it in the wishlist category.

3 Likes

WISH LISTS GODS - are you able to give an indication if this is being considered at all for the nearish future.

I don’t know, but think it’s unlikely.

Thanks for your reply.

Oh, it’s very desirable feature. I am waiting for it to be implemented for a several years.

1 Like

I had a problem when I moved my existing server behind a haproxy server which got the domain name. It is similar to the one above, where the Seafile domain also resolves to a different machine.

But from this report I got an idea. I simply added my domain to the /etc/hosts file, so the domain locally resolves to localhost. Now everything goes out over nginx port 80 and then haproxy port 443 on the other server. No need for port 8082 to be exposed.

Thus I have a different request. Instead of changing the variable FILE_SERVER_ROOT, the config documentation of Seafile and maybe the scripts should document that locally the domain used in FILE_SERVER_ROOT should point directly to the right location relative from the current machine. I personally went with /etc/hosts, but there may be other ways.