operating-system: Problem getting SMB share disk usage after upgrading to HA OS 11.3
Describe the issue you are experiencing
I am using:
HA OS 11.3 HA Core 2024.1.0 HA Supervisor 2023.12.0
When Frigate runs shutil.disk_usage(path)
it results in this error:
2024-01-05 11:49:24.300409714 BlockingIOError: [Errno 11] Resource temporarily unavailable: '/media/frigate/recordings'
What operating system image do you use?
generic-x86-64 (Generic UEFI capable x86-64 systems)
What version of Home Assistant Operating System is installed?
11.3
Did you upgrade the Operating System.
Yes
Steps to reproduce the issue
- Install frigate and configure
- All working fine
- Upgrade HA OS from 11.2 to 11.3
- See above error description
Anything in the Supervisor logs that might be useful for us?
`2024-01-05 11:49:24.300409714 BlockingIOError: [Errno 11] Resource temporarily unavailable: '/media/frigate/recordings'`
Anything in the Host logs that might be useful for us?
Error while setting up systemmonitor platform for sensor
12:48:57 – (ERROR) Sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/usr/src/homeassistant/homeassistant/components/systemmonitor/sensor.py", line 393, in async_setup_entry
disk_arguments = await hass.async_add_executor_job(get_all_disk_mounts)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/systemmonitor/util.py", line 22, in get_all_disk_mounts
usage = psutil.disk_usage(part.mountpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/psutil/__init__.py", line 2012, in disk_usage
return _psplatform.disk_usage(path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/psutil/_psposix.py", line 177, in disk_usage
st = os.statvfs(path)
^^^^^^^^^^^^^^^^
BlockingIOError: [Errno 11] Resource temporarily unavailable: '/media/Music'
System information
System Information
version | core-2024.1.0 |
---|---|
installation_type | Home Assistant OS |
dev | false |
hassio | true |
docker | true |
user | root |
virtualenv | false |
python_version | 3.11.6 |
os_name | Linux |
os_version | 6.1.70-haos |
arch | x86_64 |
timezone | Europe/Bucharest |
config_dir | /config |
Home Assistant Community Store
GitHub API | ok |
---|---|
GitHub Content | ok |
GitHub Web | ok |
GitHub API Calls Remaining | 5000 |
Installed Version | 1.33.0 |
Stage | running |
Available Repositories | 1366 |
Downloaded Repositories | 10 |
Home Assistant Cloud
logged_in | false |
---|---|
can_reach_cert_server | ok |
can_reach_cloud_auth | ok |
can_reach_cloud | ok |
Home Assistant Supervisor
host_os | Home Assistant OS 11.3 |
---|---|
update_channel | stable |
supervisor_version | supervisor-2023.12.0 |
agent_version | 1.6.0 |
docker_version | 24.0.7 |
disk_total | 48.5 GB |
disk_used | 12.8 GB |
healthy | true |
supported | true |
board | ova |
supervisor_api | ok |
version_api | ok |
installed_addons | Check Home Assistant configuration (3.11.0), Log Viewer (0.16.0), Tailscale (1.56.1.1), Samba Backup (5.2.0), Advanced SSH & Web Terminal (17.0.1), Squeezelite (0.0.17), Mosquitto broker (6.4.0), Zigbee2MQTT (1.35.0-1), Studio Code Server (5.14.2), Frigate (Full Access) (0.12.1), Music Assistant BETA (2.0.0b80) |
Dashboards
dashboards | 1 |
---|---|
resources | 3 |
views | 1 |
mode | storage |
Recorder
oldest_recorder_run | 31 December 2023 at 15:10 |
---|---|
current_recorder_run | 5 January 2024 at 12:48 |
estimated_db_size | 57.61 MiB |
database_engine | sqlite |
database_version | 3.41.2 |
Additional information
No response
About this issue
- Original URL
- State: closed
- Created 6 months ago
- Reactions: 4
- Comments: 39 (11 by maintainers)
Commits related to this issue
- Revert kernel patch causing failures on CIFS share disk usage The issue was reported upstream, waiting for a fix there. Reverting the patch for a quick resolution of the bug that breaks some things i... — committed to home-assistant/operating-system by sairon 6 months ago
- Revert kernel patch causing failures on CIFS share disk usage (#3051) * Revert kernel patch causing failures on CIFS share disk usage The issue was reported upstream, waiting for a fix there. Reve... — committed to home-assistant/operating-system by sairon 6 months ago
Hi, I found this by accident while Googling the same problem (but I had it with my desktop, I didn’t even know there was a problem with HASS too).
After doing a lot of troubleshooting involving changing the configuration in the Samba server and the mount flags in the client, I found out that nothing worked and the problem is entirely at the client, with kernel version 6.1. I was using Arch and the LTS kernel (6.1.71) and any
stat*
system call on a CIFS share (reproducible withdf
,ls -l
, etc.) would result inResource temporarily unavailable
. If I just boot with the most recent kernel (6.6.9 at the moment I write this) without changing anything, these errors go away.I did the same test in the root shell of HassOS and I’m getting the same errors when I mount the same CIFS share that had the same issue in my desktop, but no longer does after upgrading the kernel.
HassOS is also using 6.1, and the fact that the exact same error is happening with CIFS shares is probably is not a coincidence. I am in this LTS for some time (months) and I’m sure this wasn’t happening before, so there must be some regression introduced in recent versions of 6.1.x.
In a nutshell:
Reverting the offending patch seems like a slightly better solution. 11.4.rc1 should be available this afternoon/evening (CET), 11.4 likely tomorrow.
HA OS 11.4 is out with the problem resolved. I’ll keep this issue opened until a proper fix lands in the next 6.1 kernel release.
FYI: I already reported it to the stable mailing list (https://lore.kernel.org/stable/8ad7c20e-0645-40f3-96e6-75257b4bd31a@schenkel.net/), I think it would be nice if you used the same thread.
Thanks everyone (and thanks @lbschenkel especially for the extensive report and testing), I managed to reproduce the issue and started bisecting the linux-stable tree this morning, which pointed me to the specific commit which introduced the issue: https://github.com/gregkh/linux/commit/bef4315f19ba6f434054f58b958c0cf058c7a43f. Since it’s been backported to 6.6.9 as well which doesn’t show the regression, there’s likely something different in 6.1.x tree. I’ll look a bit more deeper and report it in appropriate mailing lists.
In the meantime, before the kernel issue is resolved, easiest solution is to downgrade to 11.3.rc1 (
ha os update --version 11.3.rc1
) which is missing only a few minor HAOS changes from the latest stable (and uses Linux 6.1.69).I did more experiments inside a VM. I “bisected” the LTS kernel versions to see which one started having this error with CIFS shares. It’s exactly version 6.1.70 which is being used by HassOS. Newest LTS 6.1.71 is also affected.
This is the changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.70
There were a few CIFS changes in there to fix other bugs, but I’m guessing that some of those broke the LTS kernel (perhaps some other change that should have been backported wasn’t?).
If you need working CIFS right now, the best “solution” is to downgrade HassOS to use kernel 6.1.69 or older.
no issues with rolling back to 11.2 instead of 11.1. (ha os update --version 11.1 is the command if you need it)
I’ve also updrated to 2024.1.2 core no issues.
My shares also mount just fine, please check my problem again:
2024-01-05 11:49:24.300409714 BlockingIOError: [Errno 11] Resource temporarily unavailable: ‘/media/frigate/recordings’
This looks like just the checking of resource usage fails, hence frigate reports the share as unavailable.
Please, when adding comments like “+1” to this issue, also attach logs from HAOS and details about your setup (what type of installation are you running, where is Samba share hosted). So far we haven’t been able to reproduce the issue and gathering more info is crucial for identifying the cause.
Same here. As mentioned above - rollback to 11.2 resolve that issue.