Add repair to move local data blocking a mount target

[agners]

Proposed change

When an add-on writes into a media/share directory while its network mount is not in place — e.g. Frigate recording to /media/frigate before network storage was set up, or after systemd tore down the bind mount together with a stopped/restarted data mount (#7013) — the local data blocks re-creating the mount, since mounting over a non-empty directory is refused (#7072). Until now this failed silently at Supervisor startup: the bind mounts were created as fire-and-forget tasks, so the data mount reported active while /media/<name> stayed a local directory, and the only way out was removing the data manually over SSH/Samba and re-creating the mount via the API (see #7037).

This PR surfaces the condition as a new mount_target_not_empty issue with a new move_local_data suggestion (plus the existing execute_remove). The fixup moves the blocking data to a <name>_local_recovery folder in a user-accessible location instead of deleting it, then reloads the mount:

• media/share mounts: the recovery folder is created next to the mount in /media resp. /share, so users can inspect and clean it up via the media browser, the Samba shares or add-ons.
• backup mounts: their data mount directory (/mnt/data/supervisor/mounts/<name>) is not reachable for users, so the data is moved to local backup storage instead, where stranded backup files are visible and manageable.

The relocation is inherently safe against touching share content: paths that are mount points are skipped, and renaming a live mount point or moving data across filesystems fails (EBUSY/EXDEV) rather than misplacing data. Name collisions with an existing recovery folder get a numeric suffix.

Detection covers all paths where the condition can appear: bind mount failures during load() are now awaited and routed into resolution issues instead of being swallowed as fire-and-forget tasks (blocking local data raises the new issue; other bind failures create the existing mount_failed issue), the periodic mount reload picks it up through the same error routing, and the reload fixup raises it directly when re-creating the bind mount fails on local data. A successful mount reload dismisses a stale mount_target_not_empty issue.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality to the supervisor)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue: Media NFS mount reports active but Frigate writes to local ext4 after HAOS reboot/update #7037, Fix media/share mounts staying empty after mount reload fixup #7013, Check for local data before adding or updating a mount #7072
• Link to documentation pull request:
• Link to cli pull request:
• Link to client library pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Ruff (ruff format supervisor tests)
• Tests have been added to verify that the new code works.

If API endpoints or add-on configuration are added/changed:

• Documentation added/updated for developers.home-assistant.io
• CLI updated (if necessary)
• Client library updated (if necessary)

[Copilot]

Pull request overview

This PR adds a Supervisor repair path for the case where local files/directories in a mount target prevent (re)creating a bind mount into /media/<name> or /share/<name>, by surfacing it as a resolution issue and providing a fixup that relocates the blocking data and retries the mount.

Changes:

• Convert bind-mount setup during MountManager.load() (and bind re-creation during reload_mount()) from fire-and-forget into awaited operations that route failures into resolution issues.
• Introduce a new resolution issue/suggestion pair (mount_target_not_empty / move_local_data) and implement the corresponding fixup that relocates local data to a *_local_recovery folder before remounting.
• Add test coverage for issue creation/dismissal and for the new fixup behavior (including recovery-folder name collisions).

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
supervisor/mounts/manager.py	Routes mount/bind errors into resolution issues; adds local-data issue helpers; adds relocate_local_data() job and integrates issue dismissal on successful reload.
supervisor/resolution/const.py	Adds IssueType.MOUNT_TARGET_NOT_EMPTY and SuggestionType.MOVE_LOCAL_DATA.
supervisor/resolution/fixups/mount_move_local_data.py	Implements the new fixup that calls MountManager.relocate_local_data() and preserves issues on failure.
supervisor/resolution/fixups/mount_execute_remove.py	Extends the existing remove fixup to also apply to the new local-data issue.
tests/mounts/test_manager.py	Adds tests for local-data issue creation on bind failure, dismissal after successful reload, and recovery-folder collision behavior.
tests/resolution/fixup/test_mount_move_local_data.py	Adds end-to-end fixup tests for media/backup mounts, failure retention, and missing-mount dismissal.

[agners]

Since we have already a repair for the failing mount, can't we just have it as part of that repair? Either we make a new repair "mount failed/data move needed" alongside "mount failed", but only raise one of the two.

Actually: We can have a single fixup with another suggestion, one which moves data and one which just retries (in case the user wants to resolve on its own).