Seafile Pro Docker - Elasticsearch Authentication Error

I did a test install of Seafile PE 10.0.11 using the provided docker-compose.yml and editing only volume paths & passwords. Running docker as root. Everything seems to work except elasticsearch. On the main screen I get no search results. When I expand the search box, I see a red “Internal Server Error” message under the search box.

Per another post, I confirmed in my seafevents.conf

[INDEX FILES]
external_es_server = true
es_host = elasticsearch
es_port = 9200
enabled = true
interval = 10m

Per that same post, I tried running

docker exec -it seafile /opt/seafile/seafile-server-latest/pro/pro.py search --update

The last msg I get from that command is:

[ERROR] seafes:158 start_index_local: Index process init error: AuthenticationException(401, 'None').

So… then I tried setting credentials as environment variables for elasticsearch in the docker-compose.yml and, per the docs, adding the following to my seafevents.conf.

## From 9.0.7 pro, Seafile supports connecting to Elasticsearch through username and password, you need to configure username and password for the Elasticsearch server
username = elastic           # username to connect to Elasticsearch
password = elastic_password  # password to connect to Elasticsearch

But, that didn’t help. I can manually curl -u with the credentials I created, but Seafile still returns the same error.

Then I tried disabling elasticsearch authentication completely by adding the following to the docker-compose.yml:

- xpack.security.enabled=false

This worked. I no longer see the Authentication error when running pro.py search --update and search works in the GUI.

It seems to me Seafile is, out-of-the-box, trying to send some incorrect credentials to elasticsearch or Seafile is not sending credentials elasticsearch is expecting.

Anyone see this before? Or, is running elasticsearch with security disabled reasonable?

Thanks!

1 Like

We cannot reproduce the problem with the docker image. Maybe there is something wrong in your steps.

Without password is reasonable, if you restrict the ES to be accessible only locally or specific IP address.

I recently setup seafile pro with docker and also same as you I had to modify elasticsearch.yml
with
xpack.security.enabled=false

However the log error I was seeing were completely different than your

error: AuthenticationException(401, 'None').

I was seeing

“WARN”, “message”:“received plaintext http traffic on an https channel, closing connection

I made a post about my issue here:
ht t p s ://forum.seafile.com/t/seafile-server-pro-edition-w-docker-default-docker-compose-yml-wont-connect-to-elasticsearch/18948

Were you able to find how to keep xpack.security.enabled=true and to get seafile working with elasticsearch?

If you decide to enable security in Elasticsearch, make sure that you have configured the appropriate roles and permissions for the specified username. Check the Elasticsearch documentation for details on configuring security settings. Ensure that the versions of Seafile and Elasticsearch you are using are compatible. Sometimes, certain versions of applications may have specific requirements or compatibility issues.

I have exactly the same issue - I checked all my steps and I can’t find any fault

We have updated the docker-compose file to include the option by default.

1 Like

I never found a solution to the Elasticsearch issue. But I think/hope that running the Seafile stack on a dedicated bridge network behind an Nginx reverse-proxy will be good enough.

We solved the error

[ERROR] seafes:158 start_index_local: Index process init error: AuthenticationException(401, 'None')

by managing the permissions of the volume of the elasticsearch container:
chmod -R 777 /opt/seafile-elasticsearch/data

Hello everybody !

We have the exact same problem on a Seafile 10.0.9 Pro running in cluster mode on Debian (without Docker).
The index.log shows the following error :

[ERROR] seafes:158 start_index_local: Index process init error: AuthenticationException(401, 'None').

Like @rdb suggested, I did perform the chmod -R 777 on the pro-data/search directory without any improvement…

Does anyone have a clue about what could go wrong ?