The container running doesn’t mean ha is. Just FYI.
I would reset and not restore snapshot. Just copy config directory over.
The container running doesn’t mean ha is. Just FYI.
I would reset and not restore snapshot. Just copy config directory over.
Reset? The entire config directory?
No?
I literally just said copy your config directory over and not restore snapshots.
This is one of the many reasons I hate hassio. I don’t have these issues on normal home assistant in docker since I control everything.
I’m wondering what I reset.
Hassio.
Not the config. The add-ons. The snapshots. Remove all of it. Outside of the config directory is the directory used by the supervisor container that handles all the installed add-ons and config. Delete it. Move it. Rename it. Whatever. Just power off hassio and get rid of those files. Let them be created again on next hassio startup. The config directory for home assistant stays the same
OK. Stop ha. Remove addons, share, ssl, and backup directories, then restart ha. Correct?
Try it. Just move them somewhere else in case it fails to recreate.
I don’t appear to have sufficient permissions to delete these ubuntu directories. The samba share to the W10 box doesn’t reflect the actual contents of te ubuntu directories.
I’m using the files tool.
I think you need to learn some command line and stop relying on GUIs.
Probably so. The samba shares are at “/” No symlinks to the actual directories. The location of the hassio files according to the gui is usr/share/hassio/. If I cd to usr/share I don’t see hassio with a ls -al.
No they aren’t.
Correct.
You’re using the ssh add-on aren’t you?
Yes. I’ve switched over to the native terminal application and found the hassio directory.
Time to teach some command line. I’ve moved all but the homeassistant directory to a new directory I created in /share. On restart the addons and backups remain.
There is no reason to ssh into hassio when you’re logged in locally on the host
OK. The RPi is offline right now. I’m on the NUC now.
config.json
homeassistant.json
share
ssl
updater.json
were recreated.
I’m getting the following error at the portainer installation step:
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.39/containers/create: dial unix /var/run/docker.sock: connect: permission denied.
Is your user in the correct groups? Or have you tried running as sudo or root?
I researched the commands necessary to add $USER to the docker group. rebooted the NUC and was able to execute the remaining commands. I’m getting all my sensors updated now, but still can’t connect from my external static IP. So everything is working but that. The Pi still connects from outside no problem.
Thanks very much for the tutorial. I was up and running very quickly with no errors and was able to download a snapshop from Pi, upload to NUC via SAMBA and restore backup.
The problem I had was with DuckDNS running via Hassio. It seemed to be a DNS issue in the end. This was the error code the add on was throwing:
“# ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)”
This was the solution: https://development.robinwinslow.uk/2016/06/23/fix-docker-networking-dns/
@piyush Great write up, thank you! A couple of suggestions:
--security-opt apparmor=docker-default
, you might want to update the guide to include that.should be docker volume create