Skip to main content

List what a share relocation would collide with

GET 
/shares/:name/relocation-precheck

Required role: admin. Only an account or token with the admin role can call this operation.

Example request
curl --request GET \
  --header "Authorization: Bearer $HOSERVA_TOKEN" \
  "https://$HOSERVA_HOST:8008/api/v1/shares/{name}/relocation-precheck"

What a caller shows before it starts startShareRelocation: the containers whose mounts use the share and every file of the share some process currently holds open, across the cache and every array branch. A container uses the share when a mount's host path is the share's pool path, a path inside it, or a path that holds it (/mnt/user, a disk or the cache itself), on the pool, on the cache or on a data disk; the match is made on the path as written, never through a symlink, so it reads no data disk. active is true for a container that is running, paused or restarting — one that can hold files open and that a relocation must not run beside. Listing the open files enumerates the share on the cache and on every array branch, so this is an explicit call that may wake disks — it is never polled. dockerAvailable is false, with no error and no containers, whenever Docker itself is not reachable. The answer covers both sides of the share, so it is the same whichever way the share will move. No answer is given in the cases startShareRelocation refuses before it queues a job: 409 no_cache_disk while the array has no cache disk, 409 no_array while there is no array, 409 maintenance_mode while the array is stopped, 409 migration_in_progress while an Unraid migration is unfinished and 409 database_restore_in_progress during a database restore. These are the scheduler's own admission checks, queried without submitting a job. Stopping a listed container goes through stopApp.

Request​

Responses​

The containers and open files a relocation would collide with.