Persistent storage in addons

Im currently packageing mbentley/omada-controller as hassio-addon. But I can’t find how other addons (like MariaDB) manage to store the data persintently. After a restart of the server the omada-controller instance is back to install state.

In the base image there are volumes definde. But how can I bind them? Or do I need to add symlinks in the image so all data ist saved in /shared?

my addon: ha-plugins/omada-controller at main · drummer3333/ha-plugins · GitHub

/data is the shared directory for addon options.

1 Like

Alex already made that one (I have not used it). He has lots of good ones, but uses pretty sophisticated techniques which I don’t understand: GitHub - alexbelgium/hassio-addons: My homeassistant addons

You can look at the hackjobs I did for some addons to get persistent storage: GitHub - jdeath/homeassistant-addons

Sometimes it just works out of the box, sometimes there is a variable you can set to tell the container where to store info, sometimes you need to make symlinks, sometimes you need to edit things in the container, or use a manual run command. I use trial and error. Wish it was easier, because there are a few docker images I can’t get to work. Wish it was documented better as well!

Yes, but the docs were to unspecific for me. is ist only for loading contig or can I save stuff in that directory.

Thanks, I searched for a exicting one but didn’t find anything. I will use Alexes.

As you say the docs are lacking a bit in regards to presistance. I thought you can specify bind mounts in the config.yaml. That would be the docker way.

I wish you could specify mounts. You can allow /share/ , /ssl, directories to be read or read/write in the config.yaml using the map: field, but you can’t define a volume to mount. Most docker containers need these and thus needing all the work arounds. Not sure why the dev’s don’t allow this

You can put anything in it (post install)
My addon potentially puts stuff in

/data/sbfpot/logs/%y/events << in the container

It goes to usr/share/hassio/addons/{slug}/data on the host on docker/supervisor

HAOS is mnt/share/something/something (I’m on mobile)

It’s on my addon readme anyway.

Config. Yaml sets the options. Json
The scripts get the directory from that.

The scripts generate a config that sbfspot needs, sbfspot uses to put stuff in data

Rootfs gets loaded from github to the addon

The addon is down here

Because an addon is expected to work on any of 110k+ is installs and 13k+ supervised installs. How is an addon dev supposed to predict what folders are mountable into the addon container across all those systems and os’s?

Also @HasQT gave the answer a while ago:

/data is a private, persistent space in every single addon. A folder within supervisor’s carved out space on the host is mounted to /data in every single one. It’s an unrestricted, private, persistent space for addon devs. Users don’t get access to it as the only container it’s mounted to is the addon and everything put in there survives restarts/rebuilds of the addon’s container

1 Like

I get it, thanks. Just thinking it would be nice to be able to mount a volume inside the docker to a directory inside /data/ . However, I understand the addon system is not meant to be a portainer-like. It would make it easier to adapt standard docker containers into homeassistant addons.