Could not connect to Weaviate:Connection to Weaviate failed. Details: .

Discussion
11

Q:
Self‑hosted Dify (Docker) shows the error:

Could not connect to Weaviate: Connection to Weaviate failed. Details: .

when uploading documents to the Knowledge Base.
All containers (including weaviate) are Up, but inside the Weaviate container netstat shows no listener on port 8080. Why is this happening and how was it fixed?

Summary

  • Environment: Self-hosted Dify (Docker, v1.11.2), Weaviate 1.27.0 as middleware.
  • Symptoms:
    • “Could not connect to Weaviate” error when uploading files to the KB.
    • docker compose ps shows docker-weaviate-1 as Up.
    • However, upon checking inside the container, the Weaviate process is running, but it is not listening on :8080.

Root Cause

The cause is believed to be that Weaviate’s data directory was assigned using a bind mount to a host directory.

weaviate:
  ...
  volumes:
    - ./volumes/weaviate:/var/lib/weaviate   # ← bind mount

It is highly probable that one of the following issues occurred on the host side for this path:

  • Permission / ownership inconsistencies
  • Restrictions such as ACL / SELinux / AppArmor
  • Docker running in rootless mode, restricting access to this path

As a result, Weaviate failed to initialize storage, and although the process itself existed, it was unable to properly bind to HTTP port 8080.
From Dify’s perspective, this resulted in a state where “the container is Up, but a TCP connection cannot be established,” leading to the error.

Actual Actions Taken and Resolution

  1. First, a restart was attempted with docker compose down && docker compose up -d, but it did not resolve the issue.
  2. Weaviate’s volume setting was changed from a host directory bind mount to a Docker named volume.
weaviate:
  image: semitechnologies/weaviate:1.27.0
  profiles:
    - weaviate
  restart: always
  volumes:
    - weaviate_data:/var/lib/weaviate    # Changed here
  environment:
    PERSISTENCE_DATA_PATH: ${WEAVIATE_PERSISTENCE_DATA_PATH:-/var/lib/weaviate}
    ...

# Add to the end of the file
volumes:
  weaviate_data:
  1. After making the change and restarting the containers, Weaviate started normally, began listening on 8080, and file uploads to the Knowledge Base were successfully completed.

Best Practices from This Case

  1. Named Volumes Recommended for Weaviate

    • Similar to the official docker-compose.yaml, using a named volume like weaviate_data:/var/lib/weaviate helps avoid issues stemming from host OS permissions or SELinux settings.
    • If there’s no specific need to use a bind mount (./volumes/weaviate:/var/lib/weaviate), it’s safer to use a named volume.

  2. Things to Check When Using Bind Mounts

    • Does the relevant directory (./volumes/weaviate) actually exist?
    • Check with ls -ld ./volumes ./volumes/weaviate if the user running Docker has read/write access.
    • In an SELinux-enabled environment, you might need to consider :z or :Z options, or adjust the context.
    • If Docker is in rootless mode, confirm if the path is accessible by that user.

  3. Troubleshooting “Could not connect to Weaviate” when the container is Up

    • Check if the port is actually being listened to from within the container:
      docker exec -it docker-weaviate-1 sh
netstat -tlnp | grep 8080
    • If 8080 does not appear, Weaviate has failed to start, and you should first suspect volume settings or environment variables.

  4. Backup Considerations

    • When using named volumes, Weaviate’s data is not placed in an arbitrary host directory (like ./volumes/weaviate).
    • If you want to back up based on files, you will need procedures that explicitly handle volumes, such as docker run --rm -v weaviate_data:/data ....

The conclusion of this topic is:

By switching Weaviate’s data directory from a bind mount to the host to a Docker named volume, port 8080 correctly started listening, resolving the connection error from Dify.

This completes the Q&A.