Is this still relevant?
You haven't mentioned what your host is (I take it it is Windows). From what you mentioned, I assume also, you used mapping to host system (full path) and not. named (docker managed) volumes.
In addition it would be important to know -- if your host is indeed windows -- how you installed docker (docker desktop in hyper-v, virualbox/vmware)
I go by what I got and guess to start:
The constallation Docker on Windows and host volumes -- especially for databases -- is known to cause problems (see e.g.
https://github.com/docker-library/mariadb/issues/152 or https://stackoverflow.com/questions/41343972/docker-volumes-mariadb-windows)
If my guesses are right, then two things strike me as strange though:
1. How could this mariadb docker ever have worked and
2. where do those old database-files come from?
Is it possible these are an old artefact from a different (possibly local) installation?
You imply that possibly shutting down the mariadb container some time in the past (SIGTERM) lost the connection to the volume and on restart continued to work but that does not seem to match up with other evidence you provide (it obviously did work well up until your last (first?) restart of the container).
Could something have changed with the access-rights to the files or the folder on the host (although that would speak more for a Linux host)? See https://medium.com/@nielssj/docker-volumes-and-file-system-permissions-772c1aee23ca for further information. Again, this does not explani why mariadb did still run up until the problem you noticed.
Closing (again assuming this is Docker on Windows) your problem might be much smaller now (speaking after Windows 10 2004 was released) using Docker in WSL 2 because you can use named (docker managed) volumes and still easily access these as linux folders in wsl 2 are directly mounted in Windows.
Sorry, this is probably not the answer you expected. If you clarify your situation I (or somebody else) might be able to be more specific.