Hi. I’m still having trouble getting Seafile server to work after upgrading to 6.2.2 (6.2.x). It’s running on a Raspberry Pi B+, Arch Linux ARM, and has been working and upgrading without major hiccups ever since 5.x.x. The current version of the webserver is nginx 1.12.1.
While the desktop client (on a GNU/Linux laptop) auto-syncs files, it keeps loading the libraries indefinitely, and it’s impossible to access the Seafile server through the website; it either throws a ‘502 Bad Gateway’ error message or also keeps loading indefinitely.
Nginx also serves Radicale, but that website works however.
Since I have been fiddling around with the settings they are not 100% like they were in the previous working state (in the older versions), because I was trying to accomodate the new recommended settings (to use WSGI).
UPDATE 2019-02-17:
Seems like the culprit was a faulty installation, which might have arisen after the distribution packages changed. After deleting some folders related to seahub and redeploying it, using a script that came with the distribution, seahub finally started working again (!!!). Meanwhile I tried different settings in nginx as well, so now I’m not entirely sure whether they helped or didn’t make any impact. Anyhow, thanks alot for helping out, @jobenvil ! I’m so happy that it’s working again.
Because you are listening for seafile in other port than the 80:[quote=“Captain_Rage, post:1, topic:4223”]
SERVICE_URL = https://ginger.bread.com:8001
[/quote]
Thanks for the suggestion. I tried it, but unfortunately to no avail. Today I went through different iterations and permutations of all configuration files I could find but the results ended up inconclusive. I tried to install php-fpm but that didn’t help either (assuming I configured it properly).
This is what shows when systemd starts seafile-server:
CGroup: /system.slice/system-seafile\x2dserver.slice/seafile-server@gingerbread.service
|-16989 seafile-controller -c /home/seafile/gingerbread/ccnet -d /home/seafile/gingerbread/seafile-data -F /home/seafile/gingerbread/conf
|-16990 ccnet-server -F /home/seafile/gingerbread/conf -c /home/seafile/gingerbread/ccnet -f /home/seafile/gingerbread/logs/ccnet.log -d -P /home/seafile/gingerbread/seafile-data/pids/ccnet.pid
|-16992 seaf-server -F /home/seafile/gingerbread/conf -c /home/seafile/gingerbread/ccnet -d /home/seafile/gingerbread/seafile-server/runtime/seahub.conf -b 0.0.0.0:8000
|-17008 python2.7 /usr/lib/seafile/seafileenv/bin/gunicorn seahub.wsgi:application -c /home/seafile/gingerbread/seafile-server/runtime/seahub.conf -b 0.0.0.0:8000
|-17192 python2.7 /usr/lib/seafile/seafileenv/bin/gunicorn seahub.wsgi:application -c /home/seafile/gingerbread/seafile-server/runtime/seahub.conf -b 0.0.0.0:8000
|-17193 python2.7 /usr/lib/seafile/seafileenv/bin/gunicorn seahub.wsgi:application -c /home/seafile/gingerbread/seafile-server/runtime/seahub.conf -b 0.0.0.0:8000
`-17194 python2.7 /usr/lib/seafile/seafileenv/bin/gunicorn seahub.wsgi:application -c /home/seafile/gingerbread/seafile-server/runtime/seahub.conf -b 0.0.0.0:8000
Oct 13 22:50:52 Unicorn systemd[1]: Starting Next-generation open source cloud storage with advanced features on privacy protection and teamwork....
Oct 13 22:51:46 Unicorn seafile-admin[16984]: Starting seafile-server...
Oct 13 22:51:46 Unicorn seafile-admin[16984]: Starting seahub...
Oct 13 22:51:46 Unicorn seafile-admin[16984]: Seahub running on port 8000
Oct 13 22:51:46 Unicorn seafile-admin[16984]: Done
It claims it runs on port 8000, although I set the port to 8001 in ccnet.conf and seahub_settings.py. If I recall systemd has always been displaying 8000, so it is probably not relevant.
Not sure what I should be trying next. Maybe other users that are utilizing a Raspberry Pi B+, and nginx as web server, could post their ccnet.conf, seahub_settings.py, nginx.conf and systemd configuration files? It might be helpful for troubleshooting. Thanks.
Why you don’t change your configuration to work on 443? Do you need to run your seafile server on port 8001? This is not really needed if you don’t have anything running on port 443. Due to the fact that many people configured it on 8001 instead of 443, is not really a security issue. Security through obscurity is here not achieved.
The only reason is that I don’t know any better because I’m a profound novice when it comes to these things (webservers and such, that is). Do you mean deleting ‘:8001’ from ccnet.conf and seahub_settings.py altogether and changing something to ‘443’ in nginx.conf?
Until now I’ve mostly been comparing my configuration files with the ones of other users and trying to deduct how things work.
don’t worry, we will reconfigure it. The old configuration had the :8001 at the end, but later it was changed to be more easy and work all the traffic over 443 or 80, both seahub and seafile.
Where you have :8001 in ccnet.conf and seahub_settings.py, you should delete it. Then change the 8001 by 443 in nginx. Don’t forget to delete the :8001 in the seafile blocks.
There is something wrong with your seaf-server over port 12001, this should not be there. Can you post seafile.conf and seahub_settings.py without the passwords? The other seaf-server running on 8082 is correct.
Comment # the [Network] and PORT = 10001 in ccnet.conf because this is not anymore necessary.
[network]
port=12001
[fileserver]
host=0.0.0.0
port=8082
# Set maximum upload file size to 4000M.
max_upload_size=4000
# Set maximum download directory size to 4000M.
max_download_dir_size=4000
Once I change the port to 443 (from 8001), will I have to change the address in the clients to “adress:443” instead of the old “adress:8001”, since it says in the clients to also provide adress with the port?
Now I also realize that the way Seahub is provided changed a while ago (on Arch Linux you used to have to download run the upgrade scripts manually, but now Seahub is provided as a standalone package in the AUR; Arch User Repository), and now I’m not sure which one the system uses since I have Seahub installed both explicitly as a package as well as the old folders.
This is most certainly bound to cause problems, and that is sooner rather than later. Too bad I didn’t think about this earlier.
I probably should not have ran seahub-preupgrade manually ever since Seahub also got installed through the package manager.
here is something wrong. I don’t know why you have this configuration but this is the error that I already observed with netstat. You must delete the port=12001 and the [network] clausel. You can put a route (#) in front of host=0.0.0.0 because this is the default. Only if you want to exchange it to other, you should enable it with new IP.
Yes, this is probably why I observed that you use django not from the thirdpart directory, instead from a lib directory.