pretty basic thing I want to achieve and already had realized in hassbian before migrating to hassio. Probably I just missed something.
I have some devices in my local network that run my own firmware (ESP8266 stuff).
With hassbian I just served new firmware versions on a certain port via NGINX so the devices could download it when I triggered it via HA.
Now running hassio I could already manage to do this via duckdns but downloading local firmware via internet seems a bit odd to me.
How can I serve static files on a local port?
Thank you in advance!
Basic python Webserver explained in this tut
Alright, this is working as far as the tutorial guides me, so I could download options.json from /data.
Now wanted to expose another directory, so I changed WORKDIR to:
and reinstalled the addon.
Since then nothing is accessible, just get an empty directory listing, eventhough there is a file in this folder.
Another thing, is it possible to recursively expose a directory?
You need to map additional folders in config.json
"map": ["config:rw", "ssl"],
List of maps for additional Hass.io folders. Possible values: config, ssl, addons, backup, share. Defaults to ro, which you can change by adding :rw to the end of the name.
That did the trick, thanks a lot!
Is this documented somewhere?
If yes it would be nice to point me there.
I am developing an addon that needs access to the
Adding the map to the configuration doesn’t appear to be sufficient to provide access to the home assistant base directories. Is there something else needed also?
My config.json includes the following:
As part of my debug process, I am using the Portainer addon to attach to my development addon container console. When I list the directories within the addon container, I don’t see any of the mapped directories.
bin dev home media root run.sh srv tmp var data etc lib mnt proc run sbin sys usr
What am I missing?
Do I need something in my Dockerfile to map Volumes too?
Do I need to set some additional permissions to permit contain access?
my config.json contains
and my Dockerfile uses this as:
Didn’t dig deeper on this
WORKDIR parameter since it works like this for my simple use case.
Make sure you re-install the addon after such changes, easiest done by changing the
version in config.json and performing an update.
I have a rebuilt and restarted the addon several times. Additionally, I have uninstalled and reinstalled the addon. I still do not have access to the mapped directory.
I have inspected several other
config.json files in the community addon repo. Those add-ons do not utilize
WORKDIR in the Dockerfile.
Is there another security or configuration set up required to permit mapping of the directory?
Where does the mapped directory show up?
Is it in the top directory (in other words,
Is it in the
I still don’t have resolution to this issue.
Once resolved, I would like to update the community addon tutorial for more explanation.
@talljohnson Did you ever resolve your issue? I am experiencing similar behavior.
I determined that I needed hassio to reload the add on. To do this I had to change the config.json and force hassio to recognize that the config.json has changed and this upgrade the add on. Then it worked.