Backup page listing empty when network storage is configured

[joshtbernstein]

The problem

I've added an CIFS/SMB share as a backup destination.

Server: hostname.example.com Remote Share: share\folder

After doing so, the backup page no longer lists any backups, local or on the share. Creating a backup works (it's created on the share), but isn't listed.

What version of Home Assistant Core has the issue?

core-2023.6.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Backup

Link to integration documentation on our website

https://www.home-assistant.io/integrations/backup/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Supervisor:
23-06-08 12:29:37 INFO (MainThread) [supervisor.backups.manager] Found 38 backup files

Core:
2023-06-08 12:29:47.932 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /backups/reload request
2023-06-08 12:29:47.934 ERROR (MainThread) [homeassistant.components.hassio] Failed to to call /backups/reload -

Additional information

No response

[home-assistant[bot]]

Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (backup) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of backup can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign backup Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

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

[perjury]

Same problem. 2023.7

[perjury]

I'm getting these errors in the log

Logger: homeassistant.components.hassio Source: components/hassio/websocket_api.py:130 Integration: Home Assistant Supervisor (documentation, issues) First occurred: 11 July 2023 at 21:56:57 (20 occurrences) Last logged: 09:39:34

Failed to to call /resolution/info - Failed to to call /os/info - Failed to to call /addons - Failed to to call /store - Failed to to call /backups/reload -

and Logger: homeassistant.components.hassio.handler Source: components/hassio/handler.py:557 Integration: Home Assistant Supervisor (documentation, issues) First occurred: 11 July 2023 at 21:56:57 (20 occurrences) Last logged: 09:39:34

Timeout on /resolution/info request Timeout on /os/info request Timeout on /addons request Timeout on /store request Timeout on /backups/reload request

[perjury]

I have discovered that if I reduce the number of backup files then it works. It appears as if the request to list backup files times out

[circa1665]

Having the same issue:

Logger: homeassistant.components.hassio.handler Source: components/hassio/handler.py:557 Integration: Home Assistant Supervisor (documentation, issues) First occurred: 15:49:41 (4 occurrences) Last logged: 15:50:36

Timeout on /backups/reload request

[PV-Joe]

Same problem here. The list of backup files in Home Assistant on my Fritz NAS is empty.

Before it took a while for the files to show up.

Please fix that bug. 🙏

[Yorkie71]

I believe this is a duplicate issue here. I have worked around this issue by switching to NFS.

[romainrossi]

I have a similar issue : the list is empty when the NAS is powered OFF; but the list is correctly displayed when it is ON. This append even so I have LOCAL backups (on the HomeAssistant data disk); which should appears in the list irrespective to the availability of the NAS.

Home assistant : 2023.08.3 NAS : Synology, uses SAMBA

[lldaedalusll]

Same issue here. I can't see any backups in the HA backups page, even though the backup files are there on the CIFS share and get created by schedule.

Log show the timeout messages for me as well:

2023-10-06 12:02:21.474 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /backups/reload request 2023-10-06 12:02:21.474 ERROR (MainThread) [homeassistant.components.hassio] Failed to to call /backups/reload - 2023-10-06 12:04:38.474 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /backups/reload request 2023-10-06 12:04:38.475 ERROR (MainThread) [homeassistant.components.hassio] Failed to to call /backups/reload - 2023-10-06 12:05:02.474 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /backups/reload request 2023-10-06 12:05:02.474 ERROR (MainThread) [homeassistant.components.hassio] Failed to to call /backups/reload - 2023-10-06 12:06:32.475 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /backups/reload request 2023-10-06 12:06:32.476 ERROR (MainThread) [homeassistant.components.hassio] Failed to to call /backups/reload -

Home assistant : 2023.10.0 on rPi4 NAS : CIFS Share on Strato Hidrive

PS: After deleting old backups manually on the share (with now 19 files left) I can now see my backups again in HA as well.

[jmealo]

These are all related I think: https://github.com/home-assistant/supervisor/issues/4577 https://github.com/home-assistant/supervisor/issues/4357 https://github.com/home-assistant/supervisor/issues/4358

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[elboletaire]

This is still an issue with latest versions.

[perjury]

still an issue for me too

[gzxto1]

I've started today using SMB for Backups. I ran into the same issue, but found an easy workouround which works for me. On empty backups menu I select "Upload Backups" then the windows file explorer opens, then i close it again without selecting any thing, 5 sec later my 40 backups appear in the list.

[elboletaire]

I've started today using SMB for Backups. I ran into the same issue, but found an easy workouround which works for me. On empty backups menu I select "Upload Backups" then the windows file explorer opens, then i close it again without selecting any thing, 5 sec later my 40 backups appear in the list.

Thanks for the workaround. Unfortunately does not work for me. I still see it empty.

Not sure how is it working for you anyway, since I don't see any calls whatsoever in the websockets when doing that flow. The only way I see any websocket call is by using the reload option (or the first time I access the section). Ofc it never gets the expected response... all the responses I get after a reload are just from sensors and other HA related calls, nothing related to the backups.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[jmealo]

This is still an issue. Not stale.

[PV-Joe]

Still can‘t see my backups. Hope thy will fix it soon.

[jonnybergdahl]

Please fix this.

[jhemak]

+1

[ToXinE]

This is still an issue with latest versions.

[jmealo]

Just placing some links to relevant source code in case I or someone else picks this up. I asked again on Discord and no contributors have shown any interest.

Proposed fix

Preventing the error condition

When writing a backup

• Use findmnt or similar to make sure that the network mount is in a good state when creating/writing a backup.
• If the mount is in a good state: proceed.
• If the mount is in a bad state, and a fallback location is configured: write to the fallback location and raise a notice to the user that the last backup was written to the fallback location.
• If the mount is in a bad state, and a fallback location is not configured: raise a notice to the user that the last backup failed to write.

Follow-up enhancement

• Add option to copy backups from the fallback location when the mount is restored.

Recovering from the error condition

• In the event that the mount point is a regular directory and contains valid backups, it should become the fallback directory, and a notice should be raised to the user that this has occurred.

Follow-up enhancement

• Raise notice that backups are present in the fallback location but the option to copy them automatically has not been set up.

UI Fixes

• Show fallback mount configuration guidance when network storage is the default destination and the mount fails (instead of showing the blank page). Explain how to setup robust backups with a transient storage server.

Links to relevant code bits

• It looks like the mounts are managed using systemd rather than the mount command.

https://github.com/home-assistant/supervisor/blob/375789b01927de699f2138bda3689c727e844eaa/supervisor/mounts/mount.py#L250

https://github.com/home-assistant/core/blob/7fbfd446369b8ff4526a92a2018eb00da278e383/homeassistant/components/backup/manager.py#L47C2-L48C57

  async def async_pre_backup(self, hass: HomeAssistant) -> None:
        """Perform operations before a backup starts."""
        # We can likely do a check here to see if the directory is a mount, and whether the mount is in good status

https://github.com/home-assistant/supervisor/tree/main/supervisor/mounts

[jmealo]

Architecture discussion on a proposed fixed to the Network Storage issues: https://github.com/home-assistant/architecture/discussions/1033

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[ToXinE]

still an issue when lots of backups are present in the remote directory

[FlorianWilk]

Same issue here. Wasn't a problem in the past, but since a few days. guess @ToXinE idea might be valid.

Update: I had 25 Backups files on my shared network drive. In HA the Backup-list was empty. Protocol said: Failed to to call /backups/reload - Then i moved 15 of the old backups to a subdir (10 files left) and voila, Backups in HA are shown again.

[PV-Joe]

Haven‘t tested this myself yet but maybe it is better to use the advanced AUTO BACKUP integration from HACS to solve the problem?

https://jcwillox.github.io/hass-auto-backup/

[FlorianWilk]

Haven‘t tested this myself yet but maybe it is better to use the advanced AUTO BACKUP integration from HACS to solve the problem?

https://jcwillox.github.io/hass-auto-backup/

Yes, i do automatic backups - but using a custom script instead of the above integration. But in case you want to restore your backup, or just get an overview of existing backups, the list is useful. Of course i could get an overview by looking at the NAS-Folder and restore could be done by deleteing/moving every other backupfile except the one you want to restore. But i think it would be much more comfortable to have the existing backup-list working as it should (and does, if you have < 15-20 files)

[elboletaire]

Haven‘t tested this myself yet but maybe it is better to use the advanced AUTO BACKUP integration from HACS to solve the problem?

jcwillox.github.io/hass-auto-backup

That's what I use and, as said by Florian in the previous message, doees not help/affect to the issue.

[jonnybergdahl]

Listing the files should be a very fast operation, but problem occurs because the backend needs to open each and every tar file and read the details to be able to return a complete list to the GUI. I am not familiar with how the communication between the GUI and the backdoor works, but returning data line by line might be a solution. Or return a list of files, and return detail data as it arrives.