I believe our solution here is the only one that exists which is not a great thing because it’s pretty hacky. Maybe it’s a good idea to ask @pvizeli and @balloob to see if they know of any other way of persistently mounting a remote share (NFS and SMB) — and possibly consider enhancing HA to make mounting of remote folders just a bit more user friendly rather than a startup hack. Hoping it’s already somewhere on the product road-map
Excellent to hear that all is working @insajd! This was indeed challenging when I switched over from a direct PIP install onto the Supervised solution. My reason & purpose for this mount is to dump motion triggered videos from my Ring doorbell and Blink cameras.
Once I enabled NFS4 on my QNAP then mine worked with both NFS (old) and the NFS4 mount type that you have working. Interesting that you can’t get the old NFS to work.
BTW, I also wanted to go the fstab route but changed by mind. I want my hack to be more “portable” and not impact any config files on the container — if possible. After every HassIO (supervised) upgrade, I click a button in Node RED (runs on host Ubuntu) which basically runs docker command asking the container to create a folder and then reboots the HA docker container. Otherwise HA does not start correctly if I’m listing it under allowlist_external_dirs but the folder doesn’t exist — and then I simply have the same startup like you’re doing though it’s just the full mount command rather than an fstab mount all like you do @insajd. This is what I run after every Supervisor upgrade via Node RED:
Somehow I had cifs installed in HA supervised (I am using open media vault with HA installed in docker), but after the upgrade to 115, I was unable to mount cifs share, so I switched to mounting the folder in another rpi and sending the information via mqtt… I am using this for a recording folder also, and have an automation in HA that deletes the content once I get to 100Gb of recordings.
I might try @insajd version because I might use this for other automations.
I agree that more elegant mounting option would be good to have.
Regarding the portability you’re right @JZhass. I am not using allowlist_external_dirs option, so for simple playing the media folder, I changed my shell command to be
@insajd does the mkdir actually succeed for you? Try to create some folder name that you don’t already have. I had to do it from the host where the host calls a docker command to execute the mkdir on the child container.
Wow, you just made my day @insajd … tested it and it works wonderfully. Keep in mind some admin level tasks like creating folders used to fail. Looks like that limitation is lifted… You have eliminated my need for the Node RED automation that I trigger after each HA upgrade. Thank you!
Yep @insajd cifs worked for me as well. Had to have explicit permissions for a user (couldn’t use anonymous) but it certainly worked.
I have to take it back, if the folder is listed under allowlist_external_dirs and it does NOT exist, it still unfortunately causes the error below during HA startup and only loads into safe mode HA. So I’m still having to run my Node RED -> docker on Ubuntu host -> mkdir in the HA container then restart the HA docker container.
Trying to mount my CCTV recordings to Home assistant from a NAS. however I cannot for the life of me get CIFS or NFS to work. Just keep getting permission denied, even though I can access these shares on other machines.
to simplify I am trying to just mount them via the CLI just to get a visual on errors.
mount -t nfs4 192.168.1.20:/nvr-cctv /mnt/media2
mount -t cifs -o username=USER,password=PASSWORD,domain=WORKGROUP //192.168.1.20/nvr-cctv /mnt/media2
Both comeback with failed: Permission denied
Alternatively, how else do you add a directory to the media folder browser if you are running HassOS?? Baffled and hairless
System details:
Intel NUC running HassOS 4.13
Home Assistant 0.116.2
When I was getting permission denied, because permissions on NAS were too restrictive. I was restricting to my local network IP range (192.168.8.0-255), but HassOS when connecting, showing it’s docker IP (something like 172.30.32.2). Maybe same thing with your NAS setting?
If not, try sharing security configuration of your NAS - we’ll brainstorm from there on.
Thanks for the reply @insajd
Good idea, but just tried to check the IP restrictions and I do not think i have this on my NAS. At least for SMB.
I use unRaid for my NAS, none of the usual restrictions I can see, and everyhting I have lifted just to try get this thing working at the baselevel to then build complexity on top of.
I dont see any attempts in my NAS logs either from HA trying to connect. I am fresh out of ideas now.
Screens below of the SMB settings in the admin portal
No new ideas after seeing your settings…
I’ll shoot some ideas and questions:
Is unraid and hassos on the same machine?
Can you ping nas from hassos? Ping from other machines in local network?
Does nas has some firewall in it?
Try adding -v option to mount command, it should add verbose output.
I was getting the same thing when trying to connect my Synology NAS. What ended up working for me was actually running the command through an automation. I had the commands setup as a shell_command and ran that shell_command from the automation.
I could not see the mount point from the CLI after running from the automation. I’m not too experienced with docker yet so my assumption is that the mount point is in a different location than what is accessible from the CLI.
Either way, I would love a better solution because if you need to change the command in any way or unmount it, you have to create new shell_command to unmount and then change settings, each requiring a HA restart between each.
-v didnt output anything new, does that work with the mount command?
As to the setup details. Networking wise:
HASSOS is a separate machine (Intel NUC)
UnRaid (NAS) is a different server all together, basically custom built
Both devices connect to the same switch and also same subnet (its a flat network)
HASSOSS and NAS connect to eachother and i have my HA smb shares mounted on the NAS for back up purposes so no restirctions there, ping runs fine network is fine
NAS has a simple firewall, but that isnt the issue as it allows smb connections to the server from other machines
Overall the NAS works fine, its only when I try to connect to the SMB share from HA that I get this issue, never had any propblems with this share on anyother device.
As a test I booted up my Ubuntu VM on my laptop and was able to mount the SMB share to Ubuntu. So everything works, apart from HA refusing to play! Command used for test:
mount -t cifs -o username=USER,password=PASSWORD,domain=WORKGROUP //192.168.1.20/nvr-cctv /mnt/media2
@Cyberfighter - How do you know that the shell_command mounted the share? how do you confirm this in the HA GUI?
I’ve created the shell_command and when i run the service there is nothing that lets me to believe that its mounted?
This is why i tried to see if it even mounts from the CLI running as root?
MAN! you were right! it doesnt work in CLI for soem daft reason been needlessly chasing my own tail…
@insajd original method works i was just being an idiot!
For anyone else who may be in the same boat as me this is where i went wrong, didnt understant how the media browser works!
So missing the following in my configuration.yaml
Glad you fixed it. One note though, after HA upgrade you’ll probably need to connect to the ha and recreate the /mnt/media2 folder. Not to do it, add “mkdir -p /mnt/media2;” before mount command in shell_command.
Guys, i need also add my NAS folder to my Mediabrowser folder in Hassios, but no success, I get permission denied when i do that via de Terminal addon.
mount -t cifs -o username=xxxxxx,password=xxxxx,domain=WORKGROUP //192.xxx.yy.z/music /media
