## The problem
Issue weaviate/weaviate#3153 (closed, 18 comments): Dear team
we updated to v1.19.8 and now we are having a runtime error similar to a previous issue #1897 that was fixed before.
Can you please take a look at this?
Instance running in Azure, mounted file share.
Thanks
Ahmed
`{"action":"startup","level":"debug","msg":"created startup context, nothing done so far","startup_time_left":"59m59.998647187s","time":"2023-06-18T13:38:59Z"}
{"action":"startup","default_vectorizer_module":"text2vec-openai","level":"info","msg":"the default vectorizer modules is set to \"text2vec-openai\", as a result all new schema classes without an...
## What fixed it
The panic comes from Weaviate's data files living directly on an Azure File Share (SMB) mount. The confirmed operational workaround from a user: keep the active data on local storage and sync it to the file share yourself.
1. Run Weaviate with its data dir on local disk (for example `/var/lib/weaviate`).
2. Mount the file share elsewhere (for example `/mnt/weaviate_data`) and run a periodic `rsync -av --delete /var/lib/weaviate/ /mnt/weaviate_data/` (the reporter used every 5 minutes).
3. On container startup, restore from the share into the local data dir before Weaviate starts.
Caveat: this is crash-unsafe between syncs; anything written since the last sync is lost on a crash. Weaviate also later added checksum validation on segment files, but the SMB-mount panic itself had no in-place fix in the thread.