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]

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: #4577 #4357 #4358

[github-actions]

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]

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.

supervisor/supervisor/mounts/mount.py

Line 250 in 375789b

f"Cannot mount {self.name} at {self.local_where.as_posix()} because it is not empty",

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

[iMelsom]

I also have this error, and I now only have three backups in my list.

[agners]

Do you all have the Timeout on /backups/reload request entry in the Core logs as the original poster?

[bigbear3001]

@agners i do not have those errors (or any relevant info regarding the backup list request) in the logs.

As i origininally posted in #4473 (but that got closed before any action was taken from homeassistant) i worked arround the issue by having a second NIC (WIFI + Ethernet) connected to the same network. So for me the first request for listing the backups fails with no backups found in the list and a few seconds later i get the full list of backups on the network storage. If only one NIC is connected to the network i do not get any backups.

edit: found the logs in supervisor

2024-06-12 08:45:31.843 INFO (MainThread) [supervisor.backups.manager] Found 62 backup files
2024-06-12 08:45:33.544 INFO (MainThread) [supervisor.backups.manager] Found 62 backup files

it's invoked 2 times (i have no errors there) but in the UI it only shows up on the second request and i also have no errors during backups (tested today when updating core to 2024.6.2)

[iMelsom]

Do you all have the Timeout on /backups/reload request entry in the Core logs as the original poster?

I get this in my core logs:
Logger: homeassistant.components.hassio
Source: components/hassio/websocket_api.py:135
integration: Home Assistant Supervisor (documentation, issues)
First occurred: 08:20:05 (1 occurrences)
Last logged: 08:20:05

Failed to to call /backups/reload -

While my supervisor logs simply states that:
2024-06-12 08:19:54.561 INFO (MainThread) [supervisor.backups.manager] Found 3 backup files

No backups are shown...

But during creation of a backup it ususally throws some errors in the superviser log
(please see attached file: supervisor_2024-06-12T06-28-39.543Z.log )
They may be unrelated though..

[samimasad]

same issue
ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /backups/reload request

[cooki371]

I got the same issue and I can also show some backups, when moving the rest into a sub directory.

My Supervisor log also contains a bit of information I couldn't find in this issue so far. I am not sure if it is related to the issue itself, but it appears between the logs of some unreadable backup files (NAS connection broke down) and the "Found n backup files" log.

[31m2024-07-02 16:32:02.182 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-716' coro=<WSClient.start_listener() done, defined at /usr/src/supervisor/supervisor/homeassistant/websocket.py:98> exception=ConnectionResetError('Cannot write to closing transport')>
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 105, in start_listener
    await self._receive_json()
  File "/usr/src/supervisor/supervisor/homeassistant/websocket.py", line 114, in _receive_json
    msg = await self._client.receive()
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/client_ws.py", line 280, in receive
    await self.pong(msg.data)
  File "/usr/local/lib/python3.12/site-packages/aiohttp/client_ws.py", line 160, in pong
    await self._writer.pong(message)
  File "/usr/local/lib/python3.12/site-packages/aiohttp/http_websocket.py", line 709, in pong
    await self._send_frame(message, WSMsgType.PONG)
  File "/usr/local/lib/python3.12/site-packages/aiohttp/http_websocket.py", line 675, in _send_frame
    self._write(header + mask + message)
  File "/usr/local/lib/python3.12/site-packages/aiohttp/http_websocket.py", line 702, in _write
    raise ConnectionResetError("Cannot write to closing transport")
ConnectionResetError: Cannot write to closing transport

[drstil]

Same issue and logs as in description with Core 2024.7.0 and HA OS 12.4. -> The request timed out -> how do increase the request duration (only for this request)?

[Levante75]

still an issue for me too

[revampatelier]

+1
Big issue for me too I now have 19 BU's in place across both locations local SSD and NAS but the nas has only 4 while the remaining 15 are on the SSD, I can no longer list or see my backup list so can't restore via my latest BU which resides on the NAS.
I have a connection to a Samba share.

I have tried switching back to my SSD location to delete some BU's but even that route or idea does not work 19 BU's seems to be its tipping point..

Plus I have tried all other researched fixes listed here and in other forums to the test with no result..

[Levante75]

Sure it is a problem. But in the backup you can with the 3 dos upload a bu from any location by browsing to it

…

------ Oorspronkelijke bericht ------ Van "revampatelier" ***@***.***> Aan "home-assistant/supervisor" ***@***.***> CC "Robert" ***@***.***>; "Comment" ***@***.***> Datum 31-07-2024 20:40:37 Onderwerp Re: [home-assistant/supervisor] Backup page listing empty when network storage is configured (Issue #4357)

+1 Big issue for me too I now have 19 BU's in place across both locations local SSD and NAS but the nas has only 4 while the remaining 15 are on the SSD, I can no longer list or see my backup list so can't restore via my latest BU which resides on the NAS. I have a connection to a Samba share. — Reply to this email directly, view it on GitHub <#4357 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APCEYJ6JPMTSVHDRN4YXLH3ZPEVSLAVCNFSM6AAAAAAY7XG5SSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRRGE3TGNRYGY>. You are receiving this because you commented.Message ID: ***@***.***>

[revampatelier]

Ok..
So I managed to map a windows network drive like so..
(\\x.x.x.x\share) IP and share name.. NAS share
I used the share name only not the full path.
clicked finish and it prompted auth details user name and pw.
I deleted all unnecessary BU's of of the NAS location and voila.. My list appeared as normal iterating both the SSD and NAS BU's.
So as long as it does not exceed network time out or latency or the number BU's ( below 19 BU's ) it should list your BU's
thanks for your feedback..

I hope this is addressed soonish too.. :-)

[Mikrofarad]

From my supervisor log:

2024-08-14 08:34:51.619 ERROR (MainThread) [supervisor.backups.backup] Can't read backup tarfile /data/mounts/NAS_Backup/f830cf2d.tar: "filename './backup.json' not found"

I "fixed" the empty list by removing all backup files (*.tar) from the NAS where the backup.json was missing. After that all my 22 backup files where shown in the list (and I have to wait at least 20 seconds).

[carsten-h]

I am storing the backup also via SMB on my QNAP NAS. My Home Assistant OS is running on a proxmox server.
Until today the backups are always shown, but starting from today the page shows nothing.
I cleared the browser cache, used differnet Home Assistant Companion apps on iOS/iPadOS/macOS and Android, nothing can be seen.

I see that the backups are created by the daily automation and also when I am creating a backup by hand.

But the page stays empty. I only have seven backups on the NAS.

Home Assistant OS: 13.0
Core: 2024.8.1
Supervisor: 2024.08.0

[agners]

@carsten-h your case is most likely related to a HAOS 13.0 issue with Proxmox, see home-assistant/operating-system#3532. Try revert to HAOS 12.4 and see if the problem is gone (ha os update --version 12.4).

[carsten-h]

Try revert to HAOS 12.4 and see if the problem is gone (ha os update --version 12.4).

Yes, that is working! Thank you!
Then I will wait for a new Home Assistant OS.

[TeoTN]

I just started encountering this issue. I first saw it on HA OS v12.4. I updated it minutes ago to v13.1 and the issue persists.
On a side note, it was always a rather poor UX, showing "You don't have any backups yet." for a minute or so when in fact the backups list was loading in the background, now I see that it also shows up when it in fact errors out. The connection is over SMB to a Synology NAS.

Version set

Core 2024.8.2
Supervisor 2024.08.0
Operating System 13.1 (Previously on 12.4)
Frontend 20240809.0

Logs

Web browser

Home Assistant Core

Troubleshooting steps

• Restarted the Home Assistant
• Cleared browser's storage from DevTools, performed hard refresh and re-logged in
• Ensured NAS IP address in Settings / Storage is correct and provided credentials once again
• I verified that backups are still present on the NAS and the NAS is otherwise reachable
• I upgraded Home Assistant OS from v12.4 to 13.1
• Removed ~50% of old backups

[TeoTN]

I understand that this is an open source project with zero reliability guarantees but I'm nonetheless quite surprised that such critical piece can be malfunctioning and largely ignored for over a year. If any update fails for users affected, they're screwed and have to start from scratch.

Perhaps at the very least it'd be nice to assign a label to it so that the issue doesn't automatically close?

[PV-Joe]

People put up with it and just move or delete old backups as a workaround.

[TeoTN]

I question if that's a viable long-term solution but nonetheless I just moved 50% of my backups to a completely different directory (effectively removing them from the shared space) and it's still not working.

I think (remote) backups must've been broken in one of the recent updates.

[PV-Joe]

I just moved 50% of my backups to a completely different directory (effectively removing them from the shared space) and it's still not working.

Try to leave just 10 backups.
I think it works with up to 30 and that's about it.
It works for me for sure.

[TeoTN]

Yeah, going down to 20 "did the thing", so to say. I'm beyond sure though something must've been effed up, a month or so ago it worked flawlessly with 100+ backups for me.

To add insult to injury, I wasn't able to tell which ones I'm (re)moving - I sorted them by modified date and left only ones that were modified in the last 2 months, but apparently this has left me with some old backups from a year ago or older. The backup files have just hash + .tar as their names.

All this plus absolute zero problem acknowledgement from any maintainers (the issue keeps self-closing etc) makes it a really sad state of things.

[github-actions]

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.

[Egglestron]

Still an issue.

[github-actions]

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.

[Otiel]

Still an issue