OMV5 | Docker | HomeAssistant - Data Volume Mapping Problems

I'm having some trouble / strange behaviour mapping OMV5 SMB/CIFS shares to docker volumes to run an instance of HomeAssistant.

Local docker volume seems to work perfectly but the OMV shared volume fails.

I'm hoping this is a common problem people have experienced and overcome with OMV, HomeAssistant and docker volumes.

Any thoughts, Ideas or wisdom would be appreciated .

Problem Details:

SETUP:

I'm attempting to create and instance of HomeAssistant in docker via Portainer

I would like the /config directory/files to live on OMV5 SMB/CIFS share /Data/HomeAssistant

I'm attempting to do this via a docker volume (not a bind, there appears to be some debate on the correct way to do this but docker seem to recommend volumes over binds but happy to hear alternative recommendations)

Portainer looks like it can create a Volume using CIFS (/Data/HomeAssistant)

Portainer can then map this Volume to /config and added it to a Docker Container and appears to start

Network = Host

restart policy = unless stopped

Docker installed on OMV5 - extras

PROBLEM:

/Config data does populate the OMV share CIFS (/Data/HomeAssistant) - this was confirmed via finder

BUT HomeAssistant Web Access doesn't appear to start eg ipAddress:8123 (standard HomeAssistant web port)

ATTEMPTED SOLUTIONS:

• Explicitly Map port 8123:8123 --> doesn't help
• Install HomeAssistant with the same config but with a local volume eg not a shared volume --> works perfectly as expected on ipAddress:8123

Thanks for the replies folks, they are definitely appreciated.

Well the plot thickens a little, because after I left it alone for a period of time it seem to be running correctly as if the web interface has simply taken a long time to boot. (Which is plausible given it went from running directly on a local SSD to running via CIFS again to a local HDD drive but going the long way to access the data - Has anyone seen performance issues with CIFS & OMV?)

But something still seems strange because I tried spinning up an instance of GHOST using the template and this works perfectly if using an auto created volume but the second I use a CIFS share volume it fails to load the web interface (interestingly the share doesn't seem to be populated like it did with HomeAssistant and the exposed ports are not listed in portioner )

Zoki

• So looks like I'm not using file_mode=0777,dir_mode=0777  but I'll look into these options.

gderf

• Can you please expand on why you prefer binds over volumes? (Docker documentation seems to indicate there are performance and security concern around binds but I can see some appeal on a "keep it simple" basis)
• Not sure what you are saying about absolute paths, can you please clarify? (From my perspective I would say I'm using a share "CFIS share to docker" but not sure (?) if there is even an alternative way)
• I "think" I have the permissions set correctly the files are populating the share directory (as expected)

chente

• Not 100% clear what you are after with the portainter stack. Its simply a standalone instance of "homeassistant/home-assistant" this is not a docker stack of any kind.
• The hardware config is as follows: Intel 64bit i7, 16gB Ram, Primary SSD, Secondary 3TB storage Drive, 4TB Backup USB drive Rsync (Raid not active at this stage) - OMV5 with extras (docker, portainer, yatch)

chente okay fair enough, its just a generic user "StorageUser, UID=1000, GID=100" as far as I can tell it has permission because the HomeAssistant Data populated the share this would indicate (to me at lease) connectivity, read & write permission for the user.

I'm thinking there might be some merit in gderf thinking that binding directly to the host machine directories maybe more effective as this would eliminate the need to go via the CIFS and ipAddress etc but a little nervous binding to folders behind the OMV interface as I have read some reference to these potentially (?) breaking when OMV is updated.

Zitat von chente

Sorry, I don't understand this. Can you explain it or give me a link to read this information?

chente

Sorry I have been chasing this down the rabbit hole for sometime now and I don't recall the exact reference and it maybe a miss interpretation on my behalf anyway, but the from memory I have seen reference to problems with shares / folders being created and used externally to the OMV interface. Again from memory these will not show in OMV, are likely to break on updates and generally cause problems - I translated this in my mind to "just don't do it."

On further reflection, I suspect (?) these shares/folders could still be created via OMV and simply referenced and populated from the file system behind OMV via the binding. I don't imagine that this would effect OMV in anyway other then a possible permission issue with the files created in the folders. If someone with experience doing this could confirm this is the correct way to approach the problem it would be appreciated

I just need to find where the share actually live on the file system via ssh.

Zitat von chente

The disk mounts are in /srv.

I don't see how all this can help you ...

chente

I just tested this out and it seems to work nicely by bind directly to the host file system

No CIFS, usernames, Password needed.

This does feel like hacking around the volume management part of docker and I still suspect a bug maybe at play as to why it won't work rather then a setup issue, but this is not a high security deployment so I'm not overly concerned.

Even so I still would like to know how to deploy a container with CIFS volume shares if anyone has some better insight.

Thanks for all your help

I think I will put this one down as ✅ and move on to other battles.