My setup stopped working, due to;
The system could not validate that the sqlite3 database at //config/home-assistant_v2.db was shutdown cleanly
I’ve read that a quick solution for this is to delete the database…
I’ve tried to delete the database, but it’s inside the docker container, suggested methods to delete the database don’t work;
dad3ei@brix:~$ rm //config/home-assistant_v2.db
rm: cannot remove ‘//config/home-assistant_v2.db’: No such file or directory
So, is there a way to delete the database with only the ‘ha’ commands?
If not, how can I mount the docker container filesystem from the host?, and ow, yea, I’m on a HA version of one year ago, cannot see the version, webthing crashed.
Hi, you should not have config inside the container…you should mount it to a volume outside to make HA config stuff ‘persistent’ when you update or delete the container…this is all explained in the HA setup documentation. Linux - Home Assistant (home-assistant.io)
If you indeed did not use the volume then all your current config is within the container and will be lost when you update…I am hoping/guess actually that this is not the case…please confirm or send info on how you set-it up.
I’ve installed Home assistant container on a Ubuntu server. As far as I can remember I didn’t do any customizations…
(Which is going to be replaced soon, moving to Home Assistant Operating System. So any changes on this setup will be gone in two months, so I don’t want to put any effort in making structual changes.)
So how can I delete the database?
I assume the container is not running due to the error so you cannot go to the console, right? In that case, my (there may be others) solution is to find the file from the cli.
to avoid long searches it would be good to know where the folder with container is located else also from / this will work
sudo . find -name home-assistant_v2.db
then you have the path and can delete it
That pointed me right to the database file. Thanks a lot. I’ve renamed it, and rebooted my Ubuntu server and HA came up again. The file was somewhere in the /root/ folder…
OK, please mark my post as solution then and for the next one, do (!) use a volume (see earlier post) to avoid this
I’ve already did, thanks again…