How to mount media folder in supervised docker

Tags: #<Tag:0x00007fc4117ebdf0> #<Tag:0x00007fc4117eb878>

Hello guys,

I installed the supervised Docker version of hass with this script

In the latest updates hass got a media browser and I wanted to use it. But as I don’t want to move all my files there and use my existing media folder.

Now I’m trying to figure out where I can mount the volume in Docker.
I tried to edit the file /usr/sbin/hassio-supervisor and added the line
-v /opt/media:/data/media:rw
But saving and restarting the container doesn’t seem to do anything.

Does anyone know where I can add the volume to the container?

1 Like

So if someone has the same problem here is what I did. I went to /usr/share/hassio, deleted the media folder and sym-linked another folder with my music as media. Sadly it does not work to sym-link to a folder that has more symlinks.

1 Like

Appreciate the follow-up reply; this is what I needed as well

@C0ntroller

I did it like you and deleted the /usr/share/hassio/media folder and set a symlink.
It worked!
But, if I restart my server, home assistant doesn’t start because the supervisor is giving out an error that the folder media does already exists…
Did you have no problems with this setup?

I found another way…

sudo docker exec -it homeassistant bash

to get inside the container, then

mount -t cifs -o "domain=WORKGROUP,username=xxx,password=xxx" //192.168.1.xx/Medien /media

Everthing showed up in the Media-Browser!

But I think we have to do this on every restart…
I don’t know if the fstab persists after a restart, otherwise we can put it in here…
I will try this out tomorrow.

Did you have any trouble with fstab persisting?

No. I simply created a service now, which executes

sudo docker exec -it homeassistant mount -t cifs -o “domain=WORKGROUP,username=xxx,password=xxx” //192.168.1.33/Medien /media

on server restart… works good!

Don’t mean to n00bie you but what is service now?

To automate this on system startup you can create a service!

sudo nano /etc/mountnastoha.sh

Copy to clipboard

#!/bin/bash
sleep 4m

sudo docker exec -it homeassistant mount -t cifs -o "domain=WORKGROUP,username=xxx,password=xxx" //192.168.1.33/Medien /media

sudo nano /etc/systemd/system/mountnastoha.service

Copy to clipboard

[Unit]
Description=Mount NAS Media to HA

[Service]
Type=simple
ExecStart=/etc/mountnastoha.sh

[Install]
WantedBy=multi-user.target

sudo systemctl enable mountnastoha

Are you running HassOS or HA on top of RPi/Ubuntu/etc?

HomeAssistant Supervised on Raspbian with OMV5…
Even if raspbian is unsupported I never had problems.

Yeah I am running HassOS on a VM in virtual box. Not sure how to do the above in HassOS.

Update: Please note that I found (also plenty of other people on internet) that VMware Workstation Shared Folder has very slow transfer rate and is consuming plenty of CPU. I found this post: Re: Unacceptably slow shared folders performance - Page 2 - VMware Technology Network VMTN where are some tests results and the fastest way is to use SMB over bridged network. I already have bridged network for my HA so my setup was easy and I won’t go into details with W10 and on Debian it was just two simple steps. So this is what I did:

  • Create a local user in W10

  • Share a folder HomeAssistantMedia with read-write privilege for the newly created user

  • On the Debian install CIFS to support SMB protocol

    apt-get install cifs-utils
    
  • Edit /etc/fstab file to create persistent mount

    nano /etc/fstab
    
    • Add new line:
      //host/HomeAssistantMedia/frigate     /usr/share/hassio/media/frigate  cifs  username=NewLocalW10User,password=password,iocharset=utf8  0  0
      
    • Exit nano by pressing ctrl + x and confirm saving with overwrite.
  • Manually test the mount from the fstab by running this command:

    mount -a
    

    If you see any errors solve them. Hopefully all is fine and we can proceed to…

  • Reboot Debian by running the command:

    reboot
    

And that’s it. I hope this helps to anyone :slight_smile: If yes, please give me a :heart: on this post.


Original post: I’ve spend few nights while I solved this. Firstly I had to switch from Home Assistant OS to Home Assistant Supervised, because I was not able to achieve the aim there. Here with Supervised it was little pain too, but at least it was possible and it’s working now and I hope it will be working without any issues also in the future.

My host laptop is running Windows 10 where I have VMware Workstation with Home Assistant Supervised VM. My aim was to get the camera recordings from Frigate add-on inside Home Assistant VM to the data drive on the host laptop. I didn’t care if that would be SMB or any other technology because if the host is not running than also the VM. And the host is always first available then the VM starts, so mounting is not a problem.

Thanks for sharing the findings above. Thanks to the comments I was able to get to the finish line. Once again thanks to all guys above me.

What I did is:

  • On the host create folder HomeAssistantMedia with subfolder frigate

  • In the Workstation right-click at the VM and select Install VMware Tools

  • Connect to the VM linux as a root (I use console in the Workstation and my VM is running Debian without GUI)

  • Manually mount cdrom to Debian and then proceed with installation of VMware Tools using documentation from: Manually Installing VMware Tools on a Linux Virtual Machine

  • In the VM settings in Workstation enable shared drive with option Always Enabled

  • On Debian run this command to create subfolder frigate inside media folder

    mkdir /usr/share/hassio/media/frigate
    
    • note: you can’t replace media folder with mount or symlink because hassio_supervisor container won’t start. It will fail on some error with mkdir media. So we need to mount subfolder in the media folder. That works without any issues.
  • On Debian run this command to install FUSE which is the filesystem used by the VMWare Shared Folder:

    apt-get install fuse
    modprobe -v fuse
    

    source: I get some errors related to something called “FUSE” — AppImage documentation

  • Restart Debian to apply FUSE integration to the Kernel, run the command:

    reboot
    
  • On Debian edit /etc/fstab file to create persistent mount from the host to the VM which will auto-connect after VM start:

    nano /etc/fstab
    

    Add below three lines:

    #vmware workstation shared folders
    #<server>:</remote/export> </local/directory> <fuse-type> <options> <dump> <pass>
    .host:/HomeAssistantMedia/frigate    /usr/share/hassio/media/frigate        fuse.vmhgfs-fuse    defaults,allow_other    0    0
    

    Exit nano by pressing ctrl + x and confirm saving with overwrite.
    Source: vmware - Windows Host Shared Folder in Ubuntu 20.04 - Ask Ubuntu

  • Manually test the mount from the fstab by running this command:

    mount -a
    

    If you see any errors solve them. Hopefully all is fine and we can proceed to…

  • Reboot Debian by running the command:

    reboot
    

I have rebooted my laptop, rebooted VM several time and all is still running. Frigate is saving clips and recordings directly to my 4TB data drive connected to the host.

I hope this helps to anyone :slight_smile:

1 Like

Thanks Dominik.

I used your same approach with mounting the drive within docker with systemctl, however, I used NFS instead Samba. I also changed the “-it” to “-i”, my scripts kept failing on some weird ttyl error (also redirect the error logs to ~/error.txt so that I can read them). But it worked like a charm. My external drive will now hold all my media and Frigate output.


[email protected]:~$ cat /etc/mountnastoha.sh
#!/bin/bash
sleep 1m

sudo docker exec -i homeassistant mount 192.168.86.101:/mnt/rushpath_media /media 2> ~/error.txt 1> ~/output.txt


Setup
Supervised Docker
Linux OS (Debian)
1 Dell Thin Client
1 External SSD (1 TB)
Coral UBS Stick

/usr/share/hassio does not exist on my installation of Supervisesd HASS on NUC. Any advice?

I ran into the same issue with my supervised Hassio, running on top of Debian. I tried all sorts of symlinks, but for some reason supervisor and frigate do not like syminks.
Here is what worked for me:
On a host OS, I created a subvolume in my btrfs storage array and mounted it under /usr/share/hassio/media
Both supervisor and frigate are happy

Alex

1 Like

Doesn’t work for me. I’m on NUC Supervised image, nothing I mount will stay mounted when I deploy.

I have Frigate configured to store data to my USB drive mounted in /mnt/usb_drive/ where I have folder Frigate and to that I have created soft link “Frigate” in the /usr/share/hassio/media/Frigate path. All works fine.

Will you define soft link?

My appologies. I just checked my configuration and I found I chose different strategy. Let me describe how it works.

  • I’ve mounted USB drive to /mnt/data_4TB using fstab.
  • Frigate is configured to save directly to the USB drive by volume type bind to /mnt/data_4TB/Frigate.
  • Frigate configuration is stored in Home Assistant shared/Frigate folder so it’s backuped by the HA backups: /usr/share/hassio/share/Frigate/config.yml. This location is mapped to the Frigate as volume from host Debian using again bind type volume with readonly parameter.
  • In Home Assistant I have installed Frigate NVR Proxy which is allowing to view the recordings and clips using the Media Browser in HA.

So I’m not using the soft links. I’m using bind type volume.

This is my Docker compose which I have in Portainer in Stacks:

version: "3.9"

services:
  frigate:
    container_name: frigate
    privileged: true # this may not be necessary for all setups
    restart: unless-stopped
    image: blakeblackshear/frigate:0.9.0-rc5-amd64
    shm_size: "256mb" # update for your cameras using formula: (width * height * 1.5 * 9 + 270480)/1048576 * N cameras
    devices:
    - /dev/bus/usb:/dev/bus/usb
      - /dev/dri/renderD128 # for intel hwaccel, needs to be updated for your hardware
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - source: /usr/share/hassio/share/Frigate
        target: /config
        type: bind
        read_only: true
      - source:  /mnt/data_4TB/Frigate
        target: /media/frigate
        type: bind
        read_only: false
      - type: tmpfs # Optional: 1GB of memory, reduces SSD/SD Card wear
        target: /tmp/cache
        tmpfs:
          size: 1000000000
    ports:
      - "5000:5000"
      - "1935:1935" # RTMP feeds

Hope this helps :slight_smile: