"Unmountable: Unsupported or no file system" improvements

Background

When Unraid boots or starts the array, each data, cache, or pool device is mounted in sequence based on its assigned file system. If any disk fails to mount — for example, due to an unrecognized file system, corruption, or an interrupted repair process — Unraid marks the device as unmountable and skips it. This is normal behavior and expected. But the problem arises when the system shares (appdata, system, domains, etc.) reside on a disk or pool that fails to mount, Unraid interprets their absence as if the shares simply don’t exist.

As a result:

• The share manager will recreate the system shares automatically on the array — messing up the expected file and folder locations.

• The Docker and VM subsystems will attempt to start using these recreated share locations, which are now empty.

• The Docker image file (docker.img) and/or appdata directory are missing, causing Docker to appear as though it has no containers.

• The user sees an "empty" Docker page and may assume catastrophic data loss.

• This cascading behavior is confusing because:

  • The root cause (a failed mount) isn’t clearly surfaced — Unraid reports “Unmountable” in the device list, but the Docker and share symptoms appear unrelated.

• The automatic recreation of system shares changes paths silently, masking the original configuration.

• No warning or safeguard exists to prevent system share recreation when the expected storage pool isn’t mounted.

By handling mount failures more intelligently and surfacing clear diagnostics before services start, Unraid could prevent a simple file system issue from cascading into system-wide confusion. The goal isn't to change the core mounting behavior but to add awareness, communication, and safeguards around system share recreation and dependent services.

Alternative 1: Mount failure awareness for system shares

Before recreating or redirecting any of the system shares (appdata, domains, system, etc.), Unraid should:

• Check whether the original storage location (pool or disk) is currently unmounted.

• If so, pause any automatic share creation and display a clear warning such as:

  "System shares could not be found because their storage pool failed to mount. Please resolve the mount issue before continuing."

• or:

• Offer an explicit “Continue Anyway” or “Ignore” option for advanced users.

This would prevent accidental recreation of system shares on the array and preserve the original paths until the underlying disk issue is fixed.

Alternative 2: Unified mount error reporting

Instead of only showing “Unmountable” on the Main tab, Unraid could surface mount failures in a dedicated alert banner or notification panel with context, for example:

"Cache pool 'nvme1' failed to mount (unsupported or corrupted filesystem). Docker and VM services are paused until resolved."

That makes the root cause immediately obvious and avoids misleading symptoms like missing containers.

Alternative 3: Service dependency awareness

Docker, VM Manager, and other subsystems should verify their dependent shares exist and are mounted correctly before starting. If not:

• Automatically disable those services temporarily.

• Log the reason clearly (e.g., "Docker disabled — share 'appdata' unavailable").

• Allow the user to retry service startup after remounting or repairing the disk.

Alternative 4: Mount recovery workflow

Provide a guided workflow or dialog to help users repair or re-mount affected devices safely:

• Offer links to xfs_repair, btrfs check, or reiserfsck actions.

• Display the detected filesystem type and last known share paths.

• Let the user remount a single disk without restarting the entire array.

Alternative 5: Optional “Safe Mode” for System Shares

Introduce a toggle that prevents Unraid from automatically creating or relocating critical system shares unless the user explicitly approves it.

This would be especially useful for users with multiple cache pools or mixed storage configurations.