Unable to upload or download from server after changing port on server

Seafile Server
1

[see Changing Seafile default port (443) in CentOS for previous post]

I’m running CentOS 7 with Seafile server 5.1.3.
I changed the SSL port from 443 to 44309 in /etc/nginx/conf.d/seafile.conf

server {
  listen       80;
  server_name  "";
  return 301 https://$http_host$request_uri;
}

server {
  listen 44309;
  server_name  "";

and added a firewall exception. The port works, I can get to the web interface fine.
Now when I try and upload a file via the web interface I get an “Unknown error”, and I can’t download either.
I’ve also got a Windows client that previously synced fine that’s stuck on “connecting server…”

What else do I need to change? What am I missing?

1 Like
2

Added the port to the ccnet.conf to reflect that new port?
Per the manual:

Run Seahub on another port

If you want to run Seahub on another port than the default port 8000, say 8001, you must:
stop the Seafile Server

./seahub.sh stop
./seafile.sh stop

modify the value of SERVICE_URL in the file ccnet.conf, like this: (assume your ip or domain is 192.168.1.111). You can also modify SERVICE_URL via web UI in “System Admin->Settings”. (Warning: if you set the value both via Web UI and ccnet.conf, the setting via Web UI will take precedence.)

SERVICE_URL = http://192.168.1.111:8001

restart Seafile Server

./seafile.sh start
./seahub.sh start 8001
3

I changed the service URL to reflect the port.
The web interface will allow uploads/downloads after the changes, but the windows client still says “connecting server…” when syncing the library. It will accept my log in details and also ask to accept the SSL certificate though.
Got me stumped why the client can’t sync a library.

4

You need to change FILE_SERVER_ROOT too.

1 Like
5

For a first trouble shoot: Try to enable in your windows client to enable the in advanced settings “do not verify server certificate in HTTPS syncing”. Perhaps this will already solve your "that’s stuck on “connecting server…” issue

I’ve no tried to reproduce your scenario with port 444 on https and it worked for me this way:

  1. Change in nginx your seafile.conf to port 444 (like described in your other thread)
  2. open the port 444 in your centOS firewall
  3. Forward the https port 444 to your centOS machine in your Router
  4. At least for troubleshooting you should also disable your firewall on your client (perhaps this always disturbs testing)
  5. Go on your CentOS server to seafile-install-directory**/conf/** and add the Port 444 by editing the following files:
    5.a) ccnet.conf: SERVICE_URL = https://your-dyndns-address:444
    5.b) seahub_settings.py FILE_SERVER_ROOT = ‘https://your-dyndns-address:444/seafhttp’
  6. Open your Seafile client and edit the server address the same way: https://your-dyndns-address:444
  7. reboot your CentOS server

Now you must be able to reach your seahub via this URL: https://your-dyndns-address:444
Upload should work in Webinterface (seahub). I tested it on my machines.

Also the clients should work flawlessly.

  1. Try to enable your firewalls and disable the ignoring of HTTPS verification in your clients.

This should work, at least it is on my setup

@Robbie
This 8001 Port setting that you have is usually set if you don’t use nginx, respectively if you are using the seafile server only locally, but not via dynds having it accessable from the internet. After you’ve set up nginx, the port usually has not to be present anymore in service URL (assuming you are using HTTPS on default port 443)

@daniel.pan
it is a bit unfortunate that @the1poet did split his issue (changing the default HTTPS port) into 2 threads. Would it be an option to merge them together? So this thread would be some kind of little guide automatically, for everybody who stumbles about the same issue :slight_smile:

6

Sorry Daniel. I consciously split the issue as i believed the two issues weren’t directly related (one was an OS issue relating to the firewall, and I believed the current one was directly linked to Seafile.) I can edit this post and add my question / solution if that is preferable.

7

Been busy at work today so I haven’t had a chance to try yours and Daniel’s suggestions.
Will give it a crack tomorrow and post back here with my feedback.

8

Followed all the examples and seems to be working. Will do some further testing until I’m satisfied it’s working fully.
Thanks for the advice everyone.

1 Like
9

Working externally and internally. Haven’t had any other issues since making the changes.

1 Like