404 errors on sync/backup endpoints (UGOS 1.18.x) — make sensors optional or handle 404 gracefully

[stefanodeg]

Problem

On UGOS 1.18.1.0098 (DXP2800-9B4F), two endpoints return HTTP 404 every 60s, flooding the logs:

ERROR (MainThread) [custom_components.ugreen.api] [UGREEN] GET error on /ugreen/v2/web/syncbackup/task/list?page=1&size=1000: 404, message='Not Found'
ERROR (MainThread) [custom_components.ugreen.api] [UGREEN] GET error on /ugreen/v1/web/sync/general/get: 404, message='Not Found'

Integration version: v2026.09.1

Root cause

These endpoints are not available on UGOS 1.18.x — the sync/backup module is not present in this firmware version. The integration polls them unconditionally:

• ALL_NAS_COMMON_CONFIG_ENTITIES in entities.py includes show_connections_of_all_users which polls /ugreen/v1/web/sync/general/get every 60s
• _get_backup_runtime_data() in api.py calls _get_backup_tasks() → /ugreen/v2/web/syncbackup/task/list every 60s via the config coordinator
• _get_dynamic_backup_entities() retries with /ugreen/v1/web/sync/general/get on first failure

Disabling the entity in the registry does not stop the polling — config_entities is built from ALL_NAS_COMMON_CONFIG_ENTITIES without filtering disabled entities, and get_entity_data_from_api() fetches all grouped endpoints regardless.

Suggested fix

1. Handle 404 gracefully: when an endpoint returns 404, cache the failure and skip subsequent calls (similar to how nas_online is handled). A _backup_endpoint_failed flag works well.
2. Filter disabled entities before grouping by endpoint in __init__.py, so disabled sensors don't trigger API calls.
3. Make backup/sync sensors opt-in via a config option, since not all UGOS versions support these endpoints.

Workaround (temporary)

I patched api.py and entities.py locally, but these changes are lost on every integration update:

• Added _backup_endpoint_failed flag in api.py — after first 404 on backup endpoint, skips further calls
• Commented out show_connections_of_all_users entity in entities.py

Environment

• HA: 2026.8.1 (HAOS)
• Integration: v2026.09.1
• NAS: UGREEN DXP2800-9B4F
• UGOS: 1.18.1.0098

Thanks for the great integration! 🙏

[Tom-Bom-badil]

Thanks for reporting this! Weird - I thought UGOS always comes with a pre-installed backup app. Will have a look at it ...

/tom

[Tom-Bom-badil]

Further to that: I double-checked the 'root cause' identified by your AI, and from what I understand from UGreen's official documentation, the Backup & Sync App is available in UGOS 1.18, and there are even additional features planned for the future. So, this is definitely not true:

These endpoints are not available on UGOS 1.18.x

However, it is also stated that the Backup & Sync app could be de-activated, which seems to be the case here. That would explain the 404. error. In case of problems, UGreen suggests to disable the app once, restart, and re-enable it after.

Before proceeding, please answer 2 questions:

• Is “Sync & Backup” installed and enabled in your UGOS App Center, and can you open the app normally?
• If it is installed, could you disable and re-enable it once and check whether the two 404 errors disappear?

In any case, the suggested fixes mentioned by the AI have some good points, which I will pick up and implement. Thanks,

/tom

[stefanodeg]

Hi Tom,
I feel very stupid having the AI writing the ticket, sorry about that.
Sync & Backup was not enabled by default on my system for some reason and by using Time Machine backup I didn't notice it.

Stefano

[Tom-Bom-badil]

No worries, Stefano - all good. :) There were still some good ideas that AI text, which I will implement this evening (will release beta 3 after that):

• make update coordinator not frequently querying entities that are disabled; this will be detected on startup of the integration,
• stop update coordinator querying again endpoints that have returned a 404 before.

This is just a few lines of code, but an improvement for the integration over all. Thanks for that, appreciated! :)

/tom

[Tom-Bom-badil]

beta 3 is out, enjoy! :)

/tom

[Tom-Bom-badil]

It's safe to delete it: Settings > Devices and Services > Entities tab > Filter to the left: 'unavailable' > Enable tick boxes > Select it > Menu top right: Delete selected ...

/tom

[CryptoKnight360]

Ok, I was able to disable it and remove from the custom components file. There was no way to delete it from the UI. Thanks.

[Tom-Bom-badil]

I've made a small fix for this for next beta. If no backup job is detected at all, the entity won't even be created.

/tom

[CryptoKnight360]

Hello Again Tom. Weird thing, although I removed the entity from the py file, it somehow re-appeared today. Deleted it again, will keep an eye on it. Also, if you take a quick look at the bottom of the image I included in my previous reply, you'll see that it's registered a backup which I'm assuming is actually a snapshot. What's actually causing the red or invalid entity is the "connected users" entity. Hope that helps.

[Tom-Bom-badil]

"Connections" are used by the Sync&Backup App; that's why the entity appears in the 'Backup' group of the integration.

I'll release a new beta with the quick fix latest this weekend, so you can check if the entity disappears. Note that the integration has no auto-wipe for unavailable entities, so you might have to delete the entity once more after updating (auto-wiping unavailable entities might lead to loss of recorder data, e.g. when replacing a defect disk (and many more use cases, consider e.g. a shutdown NAS) - that's why I decided to not implement it).

/tom

[avlemos]

I still get these things. are they related?

[UGREEN] GET endpoint unavailable (404), skipping until reload: /ugreen/v2/web/syncbackup/task/list [UGREEN] GET endpoint unavailable (404), skipping until reload: /ugreen/v1/web/sync/general/get

[avlemos]

hey @Tom-Bom-badil . Thanks for the quick turnaround.

Neither Sync & Backup or Snapshot are installed (only Cloud Drives).

Uptime is 12 days.

I haven't seen the error come up again in the last 24 hours, but I can keep monitoring. I guess it's possible it's only on startup.

André

[Tom-Bom-badil]

Yeah, that sounds pretty much like the intended behavior right now. The integration probes the backup/sync endpoints on startup, and if they return a 404, it logs that once and stops polling them until the next reload - just like with any other endpoint returning a 404.

I haven't found a better solution so far. Some users want backup data included in the integration, while others don't even have the Sync & Backup app installed.

I could of course suppress these messages, but that would also suppress logging for all other 404 responses, which could hide actual problems and make troubleshooting more difficult.

So if you only see those messages once after startup/reload, everything is working as intended. If they start appearing repeatedly again, please let me know. Thanks again for the report, appreciated! :)

/tom

[avlemos]

why not wrap this particular test and throw something else than a WARNING?

[Tom-Bom-badil]

That's actually a fair point. A 404 from a deliberately probed optional endpoint like 'backup' is different from an unexpected 404 during normal polling.

I wouldn't want to suppress or downgrade all 404s, because those are useful for detecting actual API/firmware differences. But I could mark these specific discovery requests as optional, so an expected 404 is only logged at debug level while still disabling further polling of that endpoint.

That would avoid hiding real 404 errors without adding endpoint-specific exception handling everywhere. I'll have a look at that, thanks! :)

/tom

[Tom-Bom-badil]

@avlemos André, pls checkout the new beta here.

/tom