Yes. Do you know which container needs the mount performed? Is it Home Assistant or an Addon?
Well, I’m not sure. I want to use it to store video clips from my Frigate add-on. By default, Frigate writes to the /media folder. I’d like to add another folder under the /media folder that is mounted to either my remote SMB share which is a USB drive connected to another Rpi 4 (preferred). I’m able to read/write to that remotely from my Windows 10 PC so I know the SMB is set up correctly. I can get to the /media folder via the file explorer in the HA sidebar so I think both HA and Frigate have access to /media.
As a plan B, I could write out to a local USB drive. Anything is better than storing them on the SD card.
So should I mount the drive under the Frigate container or would mounting it under Home Assistant accomplish the same thing (and maybe make it visible to other add-ons?)
I’m running a Hassio supervised install of Home Assistant, btw.
Thanks for your help!
Do this:
- Turn on Create Example option.
- Delete the ones you don’t care about from
/config/startup/startup.d, and delete all logs from/config/startup/logs - Turn off the Create Example option.
- Replace the contents of the scripts:
Eg.
#! /bin/bash
mount -t cifs -o user="adamoutler",password="password123" //192.168.1.100/homes /media/mount
Additionally, you can create a script just like above in /config/startup/mountScript.sh, then add the instruction
/bin/bash /config/startup/mountScript.sh
to each startup script. This will make it easier to make changes in the future.
Thanks for the tip but Unfortunately no luck. My frigate log just contains (with or without the mount attempt):
OCI runtime exec failed: exec failed: container_linux.go:370: starting container process caused: exec: “exec”: executable file not found in $PATH: unknown
OCI runtime exec failed: exec failed: container_linux.go:370: starting container process caused: exec: “exec”: executable file not found in $PATH: unknown
OCI runtime exec failed: exec failed: container_linux.go:370: starting container process caused: exec: “exec”: executable file not found in $PATH: unknown
OCI runtime exec failed: exec failed: container_linux.go:370: starting container process caused: exec: “exec”: executable file not found in $PATH: unknown
OCI runtime exec failed: exec failed: container_linux.go:370: starting container process caused: exec: “exec”: executable file not found in $PATH: unknown
When I add the mount to my homeassistant.sh I get:
mount: mounting //192.168.xxx.xxx/cams on /media/cams failed: No such file or directory
I verified that the /media/cams directory does exist.
I’m a bit of a Linux noob so I may have not gotten the mount statement right. It is:
mount -t cifs -o user=“user here”,password=“password here” //192.168.xxx.xxx/cams /media/cams
Any help would be appreciated. Thanks!
This looks like /bin/bash is not available in frigate. I’m not familiar with Frigate. Can you link me to something? Lets take a stab in the dark and try another Home Assistant method. Try replacing the shebang at the top of the script
#! /bin/bash
with
#! /usr/bin/with-contenv bashio
Sorry. this was my fault. lets make that script again.
#! /usr/bin/with-contenv bashio
mkdir -p /media/cams #make the directory. Should not fail if directory is already created.
mount -t cifs -o user="user here",password="password here" //192.168.xxx.xxx/cams /media/cams
I took a look at some Frigate Add-On source for home assistant and it looks like maybe the Shebang was removed. The startup script must have a proper Posix Shebang #! on the first line or the script will not have an executable environment. Any of the following are acceptable:
#! /bin/bash
#! /bin/sh
#! /bin/dash
#! /usr/bin/bash
#! /usr/bin/sh
#! /usr/bin/dash
#! /bin/env bash
#! /bin/env sh
#! /bin/env dash
#! /usr/bin/env bash
#! /usr/bin/env sh
#! /usr/bin/env dash
1 Like
This seems to have worked! I can now see the files on my SMB share by going to /media/cams within the home assistant media browser. Thank you!
However, when I ssh to HA and go to the /media/cams folder, it is empty. Do I also have to run the map on addon_core_ssh?
Thanks again!
I tried this in my Frigate sh:
#! /usr/bin/bash
echo "This script is executed in the addon_ccab4aaf_frigate container";
env;
But still got:
OCI runtime exec failed: exec failed: container_linux.go:370: starting container process caused: exec: "exec": executable file not found in $PATH: unknown
I’ll try some of your other suggestions tomorrow.
Thanks.
Yes. Each addon runs in a separate container. Containers each have their own set of mounts.
Just wanted to thank you for this. I just started tinkerin with homeassistant and stumbled on this while looking for a way to expose my music share to HomeAssistant (the end goal is to eventually be able to ask google home to play specific songs/playlists from my home server). I ran into an issue with your plugin when I try to run it It complains that it is unable to start
Failed to start addon
500 Server Error for http+docker://localhost/v1.40/containers/7346021e6915b0bd490d0e5aed6f035ed9226c2bbe80d6603d4c8e83f06c655d/start: Internal Server Error (“error while creating mount source path ‘/sys/firmware/devicetree/base’: mkdir /sys/firmware/devicetree: operation not permitted”)
I am using the Vitualbox image and it does not seem to have the /sys/firmware/device directory
I’m not sure that’s an issue with this particular add-on. Have you tried others? I’m not specifically looking for or working with that folder. Maybe that’s a Home Assistant bug with hardware access or something. Do you have any more insight?
I don’t have any issues with any other addons When I look at the Run on startup addon with portainer it shows the following volumes in the container
Like I said, I am new to this and I am just starting to feel around how docker containers work. I was kinda surprised that Home assistant did not have a native way to mount network shares, However maybe that should not be that surprising as google home has no way to interact with local media servers either.
I used portainer to edit the volumes and redeployed without the /sys/firmware/devicetree/base volume mapped ant that seems to have done the trick.
So it’s working now? Was it a default option or something you did earlier?
I thought I had it working, I used portainer to remove the offending volume from the container and then saved over the existing container. At that point it showed as started in portainer but not in the supervisor. At which point I restarted the VM and the offending volume came back (not sure if the change I made in portainer got overwritten on the reboot, Still figuring things out. What is odd is that the container for “run on startup.d” was the only container that referenced /sys/firmware/devicetree/base so I am not sure where it is coming from.
Ok I figured out where it is coming from. In your config.json you have “devicetree”: true,
according to the addon documentation https://developers.home-assistant.io/docs/add-ons/configuration
devicetree bool If this is set to True, /device-tree will map into add-on.
Does this addon need that set to true?
Updated. I figure if I’m getting a 1 for security, I may as well take all the permissions.
I will give it a try again tommorow
Still working through getting this to work in other containers. Haven’t had a lot of time lately. One thing I’ve noticed though is even though I have the retain logs setting set to FALSE, it still seems to append the existing logs at every restart instead of replacing them.