FEEDBACK: Data stored in `/root/.ocis` instead of mounted `/var/lib/ocis` — documentation unclear on effective data path

[KD-MM2]

Hi team,

This may or may not be a bug — it could also be a misconfiguration on my end. I'm sharing this in hopes that it might lead to clearer documentation for others.

Last week I set up oCIS for the first time, following the default configuration as a reference. I configured and mounted the volumes I intended to use for persistent storage — specifically mounting a host path to /var/lib/ocis inside the container, as indicated in the docs.

However, instead of writing data to /var/lib/ocis, oCIS appears to have been writing data to /root/.ocis. I was not aware of this at the time, and went ahead and uploaded some backup data to oCIS.

Everything seemed fine — until today, when I needed to change the network configuration for the container and ran --force-recreate. After recreating the container:

• Previously created users could no longer log in (only the admin account still worked)
• All uploaded data was gone

Because /root/.ocis was inside the container's writable layer and not bind-mounted, it was wiped when the container was recreated. My mounted volume at /var/lib/ocis was intact, but contained nothing.

I realize that the documentation mentions ~/.ocis as a default fallback depending on the environment. However, I'd like to raise two points regarding the Docker/Compose experience:

Silent Fallback ignoring Mounts: Even with a volume mapped to /var/lib/ocis (as seen in many examples), oCIS silently falls back to /root/.ocis if specific environment variables (like OCIS_BASE_DATA_PATH) aren't perfectly aligned. There is no startup warning that the app is writing to an ephemeral container layer instead of the expected persistent mount.

Documentation Improvement: Could the README and Docker Compose documentation be updated to explicitly warn users about this? A note stating "Ensure OCIS_BASE_DATA_PATH is set, otherwise data will be written to /root/.ocis and lost on container restart" would be incredibly helpful. Furthermore, printing the effective data path in the startup logs (e.g., Data directory: /root/.ocis) would catch this immediately.

Thanks for the great project — hope this feedback helps prevent others from running into the same data loss trap!

kaotd@t5810:~/selfhosted/ocis$ docker exec ocis_runtime sh -c "env | grep OCIS_DATA_PATH"
kaotd@t5810:~/selfhosted/ocis$ docker exec ocis_runtime sh -c "env | grep OCIS_BASE_DATA_PATH"
kaotd@t5810:~/selfhosted/ocis$