I have defined my desired working directory path in the FILE_STORAGE variable within the .env file, but the HPC containers using the file_storage volume don't seem to write data there. Where is the data going, and how do I fix it?

By default, simply defining the FILE_STORAGE variable in the .env file does not automatically configure the Docker named volume file_storage to use that specific host path.

When the docker-compose.yaml file defines file_storage: under the top-level volumes: section without specific driver options, Docker creates and manages a standard named volume. This volume's data is typically stored within Docker's internal storage area on the host (for example, under /var/lib/docker/volumes/), effectively ignoring the path set in the FILE_STORAGE environment variable for the volume's location.

The problematic default configuration in docker-compose.yaml usually looks like this:

volumes:
  postgres_data:
  keycloak_data:
  keydb_data:
  influxdb_data:
  file_storage: # <--- This uses default Docker volume management, ignoring FILE_STORAGE path

Solution: To fix this and ensure that the file_storage volume uses the directory specified in your .env file's FILE_STORAGE variable, you must explicitly configure its driver options in the docker-compose.yaml file. Modify the top-level volumes: section as follows:

volumes:
  postgres_data:
  keycloak_data:
  keydb_data:
  influxdb_data:
  file_storage:   # <--- Corrected configuration
      driver: local
      driver_opts:
        type: none
        o: bind
        device: ${FILE_STORAGE} # Ensures the path from .env is used

This configuration explicitly tells Docker to use the local driver and to create the file_storage volume by bind-mounting (o: bind, type: none) the host directory specified in the FILE_STORAGE variable (device: ${FILE_STORAGE}). Any container configured to use the file_storage volume will now directly access the path you intended in your .env file.

After saving changes to the docker-compose.yaml file, remember to stop and restart your services (for example, using docker compose down followed by docker compose up -d) for the changes to take effect.