Something odd is happening, any one else experienceing the below?
Just updated my HA to latest version ( 0.117.1) from 0.116, and it booted into safe mode because of the not a directory for dictionary value @ data[‘media_dirs’][‘recordings’] error message in the log.
After I deleted the config line from my yaml and rebooted, everything worked fine (minus the media obviously). However I have then added the media config backin, in exaclty the same location (top of the yaml sheet) and it all worked fine?
Any one else had these issues? Cant replicate it now… so I wonder if I have the same issue on next update.
I had no such issue, but I don’t specify media_dirs in config. AFAIK media_dirs is default included in default_config: , and it also looks into subdirectories of /media
My config is following, I have /mnt/public_m3 mounted, and I have symbolic link from /media/public_m3 to /mnt/public_m3.
Did you ever figure this one out? Exactly same configuration as yours. Can mount the network folder fine and can browse it over cli, no problems. but only local files copied into the media folder show up in homeassistant media browser. the mounted folders and files do not show up…
I have not figured this out yet. Very odd, the guys in this thread are working on the same thing: Point media_dirs: at NAS share?
I couldn’t get it to work with their syntax either, same results.
Oh I understand now. I was running the mount command in the CLI which mounts the files to HASSIO however HOMEASSISTANT is a separate docker container, so you need to run the command in this container. This is why portainer is used (easy to get a command line to the container).
This is also why the shell command works since it is homeassistant executing it inside its container.
I think this is correct, please anyone correct me if I am wrong. It works for me if I do it this way.
Hi,
Managed to create/mount nas media folder and add manually, but i cannot make script trigger automatically at homeassistant startup. Where i go wrong ?
trigger: homeassistant
event :start
action: call service
service: shell _command.mount_smbmedia_folder
in scripts.yaml i have:
shellsmb:
sequence:
service: shell_command.mount_smb_folder
in config.yaml i have
shell_command:
mount_smbmedia_folder: sudo docker exec -i homeassistant mount -t cifs -o username=xxx,password=xxx,domain=WORKGROUP //192.10.0.101/Multimedia /mnt/media
I ran into this particular issue (“Connection refused”) message when trying to mount NFS share from my QNAP. It turns out, you either have to enable “Enable NFS v2/v3 Service” option for “NFS Service” in QNAP Control Panel. Alternatively force to HA to use nfs v4 using
mount -t nfs -o vers=4 QNAP_IP:/qnap_share /mnt/media
Has anyone successfully been able to pass credentials to mount? I can mount when passing the username/password manually but when I pass credentials it fails to mount.
The command I’m trying to run is
mount -t cifs -o credentials=/config/.ssh/.cifs //10.0.0.20/music /mnt/media
and I’m receiving an error message
mount: mounting //10.0.0.20/music on /mnt/media failed: Invalid argument
Looking under the logs in supervisor → logs → host show:
CIFS VFS: No username specified
I think the credentials command is not being recognized. any idea what I’m doing wrong?
@nickcj The same just happened to me today. After updating to 2020.12.2. it restarted into safe mode with the following: not a directory for dictionary value @ data[‘media_dirs’][‘music’]
Commenting out the 1st 3 lines allowed me to restart normally. Then I uncommented the lines, restarted again, and waited 2 minutes for the Mount Music automation to trigger. I’m back in business, but I’m curious how the upgrade causes this particular configuration to break.
FWIW, before commenting out the lines, I manually created the /mnt/media directory in the homeassistant container using Portainer’s terminal. That still wouldn’t pass validation even though the directory existed. The only way I was able to recover my media is to first comment it out, restart, then put it back in and restart again. Thanks @nickcj for giving me the answer.
@tanderson1992 I wonder if its worth while tagging this as a bug?
Out of interest what are you running your HA on? mine is an intel NUC running with HASS OS hypervysor.
I submitted it as a bug here, noting that it was previously reported but not addressed because the reporter didn’t properly fill out the bug template. My bug was closed within 2 hours with a developer saying it’s not a bug because mounts must be handled outside HA. He didn’t seem to fully grasp that mounts only need to be handled outside HA for one reboot cycle, and then they can go back to working just fine. I commented on the bug, but I don’t have the ability to re-open it.
Also, mine’s HA Supervised on an RPi4, mounting a share from a QNAP NAS.
Basically, it seems you are runnig similar setup using hass OS.
If the “issue” is because mount doesnt exist due to the way that HA upgrade/upadte works vs to just a generic reboot.
How do you handle the share mount outside of HA within the hypervusor? its still an HA issue since there isnt a way to handle this from my understanding and nothing mentions this in the HASS OS documentation.
I’ve commented back to your bug post, lets see if Frenck replies with some pointers, we just need to be able to create the mount outside of the HA container, rather than boot container, then create mount which makes perfect sense and how i originally trried to do this but HASS OS wouldnt let you.
EDIT: After insisting Docker containers can’t access OS mounted drives, frenck indicated I was wrong. Sure enough, containers can be started with bind mounts. In fact, according to Portainer HA starts with 9 folders bound to system folders. I’m going to try mounting my media to OS /mnt/music and then binding homeassistant’s /media/music to the system /media/music. That might negate the error @nickcj and I experienced, as well as allow for easier mounting of the volume via the OS’s /etc/fstab.
It seems like we’re not getting much traction on the bug, and I’ve already spent more than 10 times the amount of time than was required to fix it in the first place. I’m not running HASS OS. I can mount shares on my OS, but because HA is in a Docker container, it can’t access shares mounted on the OS.
I’m just going to file this away until the next update, and hopefully will remember then to take out the configuration for one reboot cycle before putting it back in. Code shouldn’t work that way IMO, but if the developers think that’s how code should behave, I’m not skilled enough to rewrite it for them.
As a matter of fact, now I’m going to write an automation that notifies me to edit the configuration whenever the updater is triggered
Ah yes, then if you are not constrained by the HASS OS like me, you can totally bind mount the folders you want and then reference them in the HA config! your problem is thus solved and you wont ever need to worry about that line of code.
Agree on the bug report, Frenk is missing my point but i cannt be arsed to spend more time talking about it on there with him, point is HASS OS doesnt support mounts and you cannot use this feature fully basically without removing the code etc.
I used to run my HA in docker on my own OS and I may revert back to that mode, the fact that there is little interest to document the limitations of HASS OS is really bothersom and ends up being so time consuming where you just end up chasing your own tail for a fault which is actually just not a thing that is supported but not documented to say what is supported.
Rant over. Hope you get to sort your mounts out, if you want a hand with Docker give me a shout.
Hello. I did this i the terminal addon in home assistant:
mkdir -p /config/media/tv;mount -t cifs -o sec=none //192.168.10.103/tv /config/media/tv
But all i get is permission denied. What im i doing wrong?
/Jerry