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


  • Without going into details, I would say that it is a permission issue. Maybe you should post your portainer stack (omit personal info). Use </> in the menu bar. This would help to get help.

    Clear your browser's cache.

  • Can you post the volume settings in portainer?


    This works for me:


    volume created in cli by

    docker volume create --driver local --opt type=cifs --opt device=//omvXXXXXX/test --opt o=addr=omvXXXXX,username=user,password=TestUser1,file_mode=0777,dir_mode=0777 --name cif-volume


    addr= is required when using hostnames


    See the docs here: https://docs.docker.com/storag…#create-cifssamba-volumes

    If you got help in the forum and want to give something back to the project click here and write up your solution for others.

  • I suggest using binds rather than volumes. And do not use shared folders but use the absolute path instead.


    Also, the number one problem seen when using docker is having the container running as a user:group that does not have the correct permissions to access the files and folders used in bind mounts.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 6.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 16GB ECC RAM.

  • 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)
  • Not 100% clear what you are after with the portainter stack

    I wanted to know which user is configured in the container and if they have write permissions on the volume that you want to use to host the config folder. The problem referred to by gderf, this error when configuring a container is very common in this forum.

    Clear your browser's cache.

  • 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.

  • 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.

    Certain. That data was missing when I made my first post. This seems to indicate that the permissions are correct.

    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

    I would do the same. I tend to keep things simple to avoid problems and this is a procedure that works.

    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.

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

    Clear your browser's cache.

  • 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.

  • Ok I guess you are saying that the folders and shares should be created in the GUI. Yes, that is so if you want to share them. Sorry, I translate with google and sometimes I don't understand some sentences, my fault. ;)


    However, this should not affect how docker works. You can create a folder in CLI or GUI and use it in docker, no problem. You just have to make sure that the docker user has permissions on that folder. If you've created it in CLI, from there, if you want to share that folder with samba, you just go to the GUI, create the folder in the GUI with the same name and location, and then share it in samba. This I have done many times and it does not cause problems.

    The disk mounts are in /srv.

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

    Clear your browser's cache.

  • 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.


    /srv/disk-by-uuid-XXX/Data/Ghost/content/var/lib/ghost/content

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!