Direct downloads via share link fail: failed to get share link info

Seafile Server
1

In preparation of a docker migration, I have upgraded my binary Seafile community server to 12.0.14 . After that, direct downloads to shared files don’t work anymore. Seafile sits behind an NGINX proxy. I would like for this site to run flawlessly before I attempt to move to Docker.

A general sharing link such as https://my.sefile.server/f/f064404396174a67b32x/ works, and displays the according web UI page. However, the corresponding direct download link https://my.seafile.server/seafhttp/f/f064404396174a67b32x/?op=view yields a 500 Internal Server Error .

In the process of tracking this down, I found this line in logs/fileserver.log:

[2026-04-03 13:35:06] [ERROR] path /f/f064404396174a67b32x/ internal server error: failed to get share link info: Post “``http://127.0.0.1:8000/api/v2.1/internal/check-share-link-access/?type=file”:`` dial tcp 127.0.0.1:8000: connect: connection refused

So apparently there is a local API call involved, and that call fails. The curious thing is I am not running anything on port 8000:

$ ss --listen --tcp -p -n
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 2048 127.0.0.1:10101 0.0.0.0:* users:((“python3”,pid=240x,fd=7),(“python3”,pid=240x,fd=7),(“python3”,pid=240x,fd=7),(“python3”,pid=240x,fd=7),(“python3”,pid=240x,fd=7),(“python3”,pid=239x,fd=7))
LISTEN 0 4096 *:10100 : users:((“fileserver”,pid=235x,fd=6))

So the fileserver is running on port 10100, seahub is running on port 10101.

Is it possible that some part of Seafile is missing out on my custom port setting, and tries 8000 instead?

Or is a required component not runnin on my system?

Any help tracking this down will be greatly appreciated.

Thanks,
Florian

2

The error you are seeing:
dial tcp 127.0.0.1:8000: connect: connection refused

…is a result of a change in Seafile 12.0. In this version, when a user accesses a direct download via a share link, the fileserver component makes an internal API call to Seahub at http://127.0.0.1:8000/api/v2.1/internal/check-share-link-access/ to verify permissions.

Because you have Seahub listening on port 10101 instead of the default 8000, this internal request is failing.

How to resolve:

The most reliable way to fix this while maintaining your custom ports is to ensure that Seahub is accessible at port 8000 on the loopback interface (127.0.0.1), as some internal components in Seafile 12 currently expect this default port for inter-process communication.

Alternatively, if you are using Gunicorn to run Seahub, you can check your conf/gunicorn.conf.py and ensure that it binds to port 8000 in addition to your custom port, or revert to the standard Seafile configuration which uses port 8000 for Seahub and 8082 for the fileserver, then handle your port mapping at the NGINX proxy level.

This behavior was recently confirmed in an internal ticket:

If you plan to migrate to Docker soon, please note that the official Seafile Docker image handles these internal communications automatically within the container network using the default ports, which should resolve the issue once you complete the migration.

1 Like
3

I have removed/reverted all custom port settings, and now direct downloads work flawlessly. Thanks for the hint.

As a sidenote, I was expecting that setting a custom port for Seahub would propagate through the whole application, and all subsequent API calls would honor that setting. That some internal components kept insisting on the default port 8000 was somewhat unexpected. Then again, reverting everything to default should have been an obvious fixing strategy on my part. Glad everything works now.