array
Array start and stop / maintenance mode (hoserva array stop|start), and acknowledging a degraded array (hoserva array acknowledge-degraded).
Stop the array
Enters maintenance mode (`hoserva array stop`): refuse new jobs and interrupt non-resumable jobs, shut down running VMs, stop containers, stop Samba and NFS, then unmount share paths, the catch-all and data disks — the same list the Stop array confirmation dialog shows. Parity is not written. A failure leaves maintenance mode active so nothing new starts against a half-stopped array. `confirm: true` is required. Refused with `disk_upgrade_pending` while a data-disk upgrade is pending: the array is already stopped for it, and nothing is stopped, signalled or unmounted.
Start the array
Reverses `stopArray` (`hoserva array start`): mount disks, the catch-all and share paths, then start services in the reverse of stop order, and exit maintenance mode only once every step succeeds. Refused with `storage_not_ready` when the storage gate is not ready — nothing is mounted. Also refused with `disk_upgrade_pending` while a data-disk upgrade is pending — queued, running or interrupted at any checkpoint; the error names the job to resume or cancel, and nothing is mounted. Once the disks are mounted, each must hold the filesystem SQLite names for it before the pool or any service starts; otherwise it is refused with `array_disk_mismatch`, the disks are unmounted again and maintenance mode stays on.
Acknowledge a degraded array
Records the user's explicit choice to proceed while the array is degraded (`hoserva array acknowledge-degraded`): the daemon acknowledges the missing disk on its live storage gate and then runs the exact not-ready to ready transition a returning disk reaches: mounting and confirming the pool, then starting every enabled, unmasked service unit that depends on it (Samba, NFS, Docker, libvirtd), never through a shell and never by a second mechanism. The acknowledgement itself survives every later rebuild of the daemon's array sequence (a share change, a disk-topology change, a daemon reload) for as long as the same disk stays missing. Refused with `array_not_degraded` (409) when nothing is currently missing — acknowledging a degraded state that does not exist would let a stale acknowledgement outlive the situation it was about. Refused with `array_services_not_started` (409) when the acknowledgement itself succeeds but the transition it triggers does not actually start anything — the array is in maintenance mode (`hoserva array stop`), or mounting or confirming the pool fails — so this never reports success over services that never came up — in that refusal case `arrayDegradedAcknowledged` on a later `getStatus` still reports true (the acknowledgement stands) while `storageServicesReleased` stays false, so a client must check both before ever telling the user services are running. `arrayDegraded` on the returned status stays true for as long as the disk is still missing — acknowledging never reports a degraded array as healthy — and `arrayDegradedAcknowledged` becomes true instead, the field the persistent banner and top-bar pill use to show 'acknowledged, running degraded' rather than clearing the warning outright.