Safe mode with media_dirs specified after update to 2020.12.2

[tanderson1992]

The problem

This seems to be a dupe of 41544 which was closed because the template wasn't filled out properly. I'll endeavor to fill mine out correctly.

After updating from 2020.12.1 to 2020.12.2, HA started in safe mode with an error about the media configuration not a directory for dictionary value @ data[‘media_dirs’][‘music’] I was able to fix the issue by commenting out the media_dirs definition, restarting the server, and then un-commenting the same 3 lines and restarting again. In the end, I once again have the system working in normal mode with the media browser populated, but two questions remain:

1. Why did the update cause this component to fail?
2. If something was broken, how did restarting the system one time fix the issue?

Environment

• Home Assistant Core release with the issue: 2020.12.2
• Last working Home Assistant Core release (if known): 2020.12.1
• Operating environment (OS/Container/Supervised/Core): Supervised
• Integration causing this issue: Media Source
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/media_source/

Problem-relevant configuration.yaml

homeassistant:
  media_dirs:
    music: /mnt/music
shell_command:
  mount_nas_music_folder: mkdir -p /mnt/music;mount -t nfs <ip>:/share/CACHEDEV1_DATA/Music /mnt/music

Traceback/Error logs

I accidentally truncated the error and then let it get overwritten before I was able to re-copy the entire line. It was an error in line 1 of configuration.yaml shown above that contained not a directory for dictionary value @ data[‘media_dirs’][‘music’]. Because restarting one time with the lines commented fixed the issue, I'm unable to re-create it to copy the full log entry.

Additional information

Before commenting out the homeassistant, media_dirs and music lines, I tried manually creating the folder /mnt/music using Portainer's shell on the homeassistant container. After that the configuration validation failed, and the system again restarted in safe mode. After commenting out the lines, the system started normally. I gave it a few minutes to finish, un-commented the 3 lines, and restarted again. This time the system restarted normally, and the Media Browser displays my media files. I got the idea for this fix (and for mounting the NAS files in the first place), here.

[probot-home-assistant]

media_source documentation
media_source source
_{^{(message by IssueLinks)}}

[frenck]

This is not an bug, but you end up getting in a situation where Home Assistant is starting (or checking configuration) while the media dir doesn't exist yet.

You need to handle mounts outside of Home Assistant (to ensure the media folder exists when Home Assistant starts).

Happy New Year 🥂

[tanderson1992]

I appreciate the quick comment, but why does it work fine through multiple server restarts and then fail for one time when the system is updated, then go back to working again? Where else can the mount happen that will allow HA to properly start? I didn't properly explain above. I made the directory in Portainer and mounted it before forcing the server to restart. It still started in safe mode. One restart without those 3 lines in my config, and then the system can accept my original config again.

Happy New Year!

[frenck]

but why does it work fine through multiple server restarts

Once the mount exists, it will work (as it renders your shell command useless at that point).

Where else can the mount happen that will allow HA to properly start?

That is a system administration question, so a bit out of scope for our project. But that depends on the system you are running on how or where to do that. But you shouldn't manage these things inside Home Assistant Core automations/integrations.

[nickcj931]

@frenck I get what you are saying, but in my instance i am getting the same issue as the OP, I run HA using HASS OS on an intel NUC.
How do you handle the mounts within the propriotry HASS OS? it is not overly clear.

[frenck]

HassOS does not support mounting filesystems.

[nickcj931]

Then how do you propose we do what you say in the post above?? Im a bit cofnused the fix you say is to handle the mount outside HA but HASS OS doesnt support the fix??

[frenck]

In that case, HassOS might not be your installation method of choice. HassOS does not support it, reporting a bug with the core because your workaround doesn't work, isn't a bug.

Each installation methods has pro's/con's and have different levels of technical capabilities (or requires different levels of technical knowledge).

[nickcj931]

I totally get what you are saying frenck, and agree, however as per OP the problem seemed like a bug since none of the documentations say this isnt possible. It works one day then on update it doesnt work certainly seems like a bug when you remove the line, reboot, add it back fixes the issue.

Also the lack of HASS OS support for remote mounts isnt listed anywhere, so how do you know what the pros and cons are when you make the decision on which approach to follow.

Just saying what you are saying above because you know the ins and outs of the system and assuming everyone has that knowledge isnt really an answer. If this is a limiatation this should at least be listed, unless i am not seeing it in the current doc then please point us in that direction that would be really helpful.

[frenck]

seemed like a bug since none of the documentations say this isnt possible

That is an incorrect statement. Media dirs requires valid folders, the configuration checks this and concludes the folder doesn't exist.

Also the lack of HASS OS support for remote mounts isnt listed anywhere

It also doesn't list it does. But that is a bit out of scope for this discussion. We have other channels for that.

The bug report given isn't a valid report, as the configuration validates the folder exists, which, because of the given code snippet, isn't guaranteed.

[tanderson1992]

but why does it work fine through multiple server restarts

Once the mount exists, it will work (as it renders your shell command useless at that point).

I don't think this is correct. As I understand it, every time HA restarts, the mount point needs to be recreated because it's lost when the container restarts. If I open a shell in the homeassistant container right after a restart, /mnt/media doesn't exist. 2 minutes after start, the shell command mount_nas_music_folder executes in an automation. Then the mkdir executes and the share is mounted.

HA configuration passes and successfully restarts dozens of times with the configuration I posted. I'm new to HA, and it's not uncommon to restart the server 5-10 times a day as I mess with various settings and new components. However, after the system upgrade, the configuration won't validate until the server starts just one time without the posted configuration. Then it goes right back to working perfectly with the configuration as originally shown. It has survived multiple UI restarts, some restarts forced from Portainer, and a complete shutdown of the RPi when the power went out. Something in the update process temporarily causes it not to work.

What you're saying is no doubt correct; the error is a result of the directory not existing when that configuration line is read. The confusion comes from the fact that restarting the device any number of ways doesn't cause this to happen. It seems to be only a system update that causes it to happen. Since you have better insight into the project, do you care to take a guess as to where in the process mounting commands can be issued to the container so that it doesn't cause this error after a system update? Again, I appreciate your time on this.

[frenck]

Since you have better insight into the project, do you care to take a guess as to where in the process mounting commands can be issued to the container so that it doesn't cause this error after a system update? Again, I appreciate your time on this.

As said, that depends on your OS of choice. Please consult the documentation of the chosen operating system, as that one has to create the mount (before HA starts). In case you are running the Home Assistant Operating System; that one doesn't support the mounting of shares.

[tanderson1992]

As said, that depends on your OS of choice. Please consult the documentation of the chosen operating system, as that one has to create the mount (before HA starts). In case you are running the Home Assistant Operating System; that one doesn't support the mounting of shares.

Except mounting shares on the OS has no impact on a Docker container. HA can access shares that are mounted within the container, but OS mounted shares are not accessible to it. You stated the configuration worked before because the mount existed, but that's not how it works. When HA starts, the /mnt/media folder doesn't exist because it's wiped out every time the container restarts. Then it's created 2 minutes later. Rinse and repeat an infinite amount of times until the update process somehow breaks it for just one cycle.

I'm not going to go round and round, because you think the mounting of shares is our problem, and I don't entirely disagree. But there's got to be something going on in the update process that only temporarily breaks this method of mounting one time before going right back to working with this method of mounting.

[frenck]

Except mounting shares on the OS has no impact on a Docker container.

That statement is incorrect. Docker containers can mount in custom mounts if you want (that is, if you are running the Home Assistant Container installation method).

If you run a Supervised installation method on a custom operating system (not to confuse with Home Assistant Operating System), a subfolder of an existing mount can be used. E.g., /media/<mount> or /share/<mount>. Please note, that those kinds of customizations is all out of scope for the project.

[tanderson1992]

That statement is incorrect. Docker containers can mount in custom mounts if you want (that is, if you are running the Home Assistant Container installation method).

If you run a Supervised installation method on a custom operating system (not to confuse with Home Assistant Operating System), a subfolder of an existing mount can be used. E.g., /media/<mount> or /share/<mount>. Please note, that those kinds of customizations is all out of scope for the project.

Well, you taught me something new. I was working on my extremely limited knowledge of Docker and the shared wisdom of the discussion I linked in the bug report. I just discovered Docker allows bind mounts that map container folders to OS folders. As you said, it's outside the scope of the discussion, but it's good to know I have another avenue.