I’m using Seafile server 6.2.5 on Linux (Debian 9) from the .tar.gz bundle. When first setting things up all went well and seahub was listening on 0.0.0.0:8000 . However, when I wanted to run the system as a user other than root, when I start it up it will only listen on 127.0.0.1:8000 … While this normally isn’t an issue, I do want another machine to be able to connect over a VPN acting as a proxy forward via nginx to the system I’m running seafile on.
My question is, how can I force seahub to listen on 0.0.0.0 instead of restricting to 127.0.0.1 if the user isn’t root?
I’m not certain I understand your goal here, but listening on port 0.0.0.0 means that you are listening for any ip address on the local machine, regardless of subnet it’s coming from. IE, if your machine has two NIC cards or two IP addresses, for example, listening on 0.0.0.0 would allow you to access the API from either of those two IP address subnets. This if far less secure than listening on a single port, and is not good practice.
You also mentioned that you do not want another machine over a VPN to access it. Are you saying that you have a VPN server setup in your network, or are you saying that there are concerns about someone subscribing to a VPN service in order to browse privately? Keep in mind that IP masking is fairly simple to do, with or without a VPN.
So, can you please let us know what it is you are trying to do? Are you just wanting to use Seafile within the local network without access from the outside world? Are you using a reverse proxy with Seafile?
Yes, I’m well aware that of what listening on 0.0.0.0 means…
What I want to do is have seafile listen on 0.0.0.0 on port 8000 but running under a different user (i.e. NOT root). When I do this, it seems ‘jailed’ to listen only on localhost (127.0.0.1) and I don’t know why.
I am not concerned with security… I have that well in hand. I have an outside machine and wish it to be a proxy and communicate with the file server machine over the VPN.
To make it easier to understand…
netstat -ln | grep 8000 (when running seafile as root)
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN
netstat -ln | grep 8000 (when running seafile as a non-root user)
tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN
I want the top one but without running seafile as root… make sense?
Yes, I understand the premise of 0.0.0.0 and 127.0.0.1 and that you would rather listen on 0.0.0.0. What I don’t understand is how that’s limiting you from accessing Seafile via a VPN.
Because what want to do is have the nginx host proxy through to the seafile server that is listening on 0.0.0.0 … now this works fine if seafile is running as root, however, I would rather run it as a non-root user. Now I’m having problems since magically seahub is only listening on 127.0.0.1:8000
Let’s just forget the VPN thing.
Can seafile be made to listen on all IPs when it’s running as a non-root user. That’s the crux of the matter.
Finally figured it out… MY own stupid fault.
In an init script I had used on another system, the ‘fastcgi’ setting was set to true which apparently makes it bind to 127.0.0.1 instead of 0.0.0.0 so it wasn’t anything to do with root versus non-root, it was the fast-cgi flag. Ugh.
restricts to 127.0.0.1
listens on 0.0.0.0
PS: This was where the init script came from, if anyone uses it: https://manual.seafile.com/deploy/start_seafile_at_system_bootup.html
I just checked one of my Seafile server implementations. I didn’t log in as the root user and ran a netstat. My seahub is listening on 0.0.0.0:8000. The fileserver portion of seafile (port 8082), however, listens on localhost.
I’m not certain why logging in as root vs a non-root user is having an effect in your instance.
NGinx reverse proxy
In the Seafile settings of the webui, my service url is set to the external address used to access it. What does your service url reflect?
Just saw your latest reply… Fastcgi is deprecated, and will be eliminated from Seafile soon. The changelog in the manual details how to switch the implementation over to WSGI rather than fastcgi.
And, sorry for the confusion. I thought you were trying to log in as root or another user, and then starting Seafile and getting that problem. Didn’t realize you were talking about Seafile having been started from system startup, and then trying to use it.
My bad for not knowing how to explain what I was meaning.
Good to know fastcgi ‘mode’ is deprecated anyway.
I’ve been using Seafile for years. I used to host it on a dedicated server but no longer wish to have it there. I have recently migrated it to my home file server which has much more space available but I still wanted to retain the accessibility from anywhere else outside my home network. Using DNS any client within my home network talks directly to the file server and its nginx proxy. Outside the network a client uses the nginx proxy on my hosted VPS but Seafile traffic is directed over my VPN
Got ya… But, it’s working now and that’s what matters. And, you learned about fastcgi, so you won’t have a surprise when they release a version that doesn’t support it.