QNAP’s Resize Volume Wizard example from its 2024 support article. The displayed capacities illustrate a limitation; they are not recommendations for your pool.
A QNAP QTS pool can run short of free capacity while Windows or File Station still shows free space inside a thick volume. The volume has already reserved that space from its parent pool. First identify which layer is short of capacity and whether there is a separate RAID fault; deleting arbitrary files or resetting permissions may address neither problem.
Use this guide for QTS volume-based storage, including a reported Read/Delete symptom. Record the exact pool and volume states before changing anything. The allocation and maintenance examples follow QTS 5.2.x documentation; QuTS hero shared folders and QES appliances need their own operating-system procedures.
Capture the pool, volume and RAID evidence separately
In Storage & Snapshots > Storage > Storage/Snapshots, identify the affected pool and every volume or LUN using it. Record pool capacity and available space, volume type and allocation, live-data usage, snapshot usage and reservations, plus the timestamp of the failed write. Save the exact application error as well as the storage status.
| Evidence | Working interpretation | Next useful check |
|---|---|---|
| Pool Threshold Reached | Usage crossed the configured warning threshold | Compare real available space and rate of change with the alert policy |
| Pool Space Low | Pool availability may affect data, snapshots or applications | Inspect allocation, reclaimable space and snapshot reservations |
| Degraded or Rebuilding | A RAID-related condition is present | Record the affected RAID group and disk health before capacity changes |
| Read-Only with a Not Active RAID group | This is not merely the configured usage threshold | Preserve evidence and obtain storage-recovery guidance |
| Only one application cannot save | The scope may be narrower than the whole pool | Compare a disposable file write and that application’s exact error |
QNAP distinguishes these pool states in its status reference. A threshold warning is not equivalent to a degraded RAID group, and a Read-Only pool may involve a Not Active RAID group. Follow the observed state rather than assuming every red or amber message has the same remedy.[1]
Coordinate the pause of nonessential affected write jobs if capacity is exhausted. Preserve logs and the recovery copy. If disk errors, missing storage objects or an unexpected RAID state accompany the space warning, stop treating the incident as routine housekeeping.
Explain the apparently contradictory free-space numbers
Thick-volume capacity is allocated from the pool in advance. Deleting a file frees space inside that volume, while thin-volume deleted space can be reclaimed into the pool. A static volume is directly on a RAID group, so the pool-based diagnosis does not apply in the same way.[2]
Illustrative example: an eight-unit usable pool contains a six-unit thick volume and another allocation of nearly two units. The six-unit volume holds only two units of live files. Its four internally empty units explain the client reading, but those units remain part of its six-unit pool allocation. Do not add them to the pool’s unallocated balance. Snapshot changes and reservations must also be considered separately.
For a thin volume, distinguish its configured maximum from real physical pool space. Several overallocated volumes can each appear capable of accepting more files even though they share a finite pool. Check the combined demand, not just the affected user’s share.
Choose a remedy whose consequences you can accept
QTS provides a pool-level Manage > Actions > Free some space view. Available actions depend on the pool’s objects and configuration. Review the choices and the recovery requirements before execution.[3]
| Candidate action | When it can help | Consequence to approve first |
|---|---|---|
| Thin-volume space reclaim | A thin volume has reclaimable space after approved deletion | Confirm the target volume and measure pool space after reclaim |
| Remove selected old snapshots | Retention review identifies recovery points no longer needed | Those recovery points are lost; do not delete all snapshots blindly |
| Reduce unused guaranteed snapshot reservation | A reserved amount is genuinely no longer required | Less guaranteed space remains for future snapshots |
| Resize an eligible thick volume | The installed release and current state permit shrinking | Access interruption and the new capacity must fit the data |
| Convert thick to thin | A reviewed conversion is appropriate for this workload | QNAP documents service interruption and deletion of all volume snapshots |
| Expand a supported pool | The exact model, RAID layout and components permit expansion | Verify compatibility, backup and the correct expansion procedure |
The QTS 5.2.x resizing guide says a thick-volume shrink returns freed capacity to the parent pool and makes the volume unavailable during the operation. That does not prove a shrink will be available in every full-pool state. If the action is unavailable, do not force it through an unrelated command or improvise a conversion.[4]
A thick-to-thin conversion is a significant change, not a harmless clean-up button. QNAP’s pool-space procedure explicitly states that it stops the volume’s services temporarily and permanently removes that volume’s snapshots. Preserve a separately recoverable copy, review retention obligations and schedule the change before considering it.[3]
Retest the storage layer and the real workflow
After an approved action, refresh the pool and volume views and record what actually changed. A deletion that raises volume free space but leaves pool availability unchanged may be behaving exactly as the thick allocation predicts. A thin reclaim should be evaluated against the pool result, not just a disappearing progress dialog.
Use a disposable file with the intended ordinary account to test create, edit, rename and delete. Then test the previously failing application, relevant backup job and snapshot operation. Do not announce recovery because an administrator can browse existing files. If the observed status or write failure remains, preserve the new evidence and escalate rather than stacking several unmeasured changes.
Use an HBS restore test when the incident exposes uncertainty about the recovery copy. A local snapshot plan and a separate backup must be evaluated for the failure each can actually cover.
Prevent a repeat by monitoring the right object
Review the pool’s alert threshold and response owner. QTS raises a warning when used pool space reaches the configured threshold; changing that threshold changes the warning, not physical capacity.[5] Track time-to-full using observed change, planned imports and snapshot growth, with enough time to approve a retention or expansion decision.
Inspect global snapshot settings as well as per-object retention. QTS documents policies that can automatically delete snapshots under low-space conditions, and exclusions such as permanent snapshots. Do not enable a broad automatic deletion policy simply to silence a warning without accepting its recovery impact.[6]
For a permanent redesign, return to the QTS and QuTS hero deployment plan. ALLMSP’s QNAP support and hardware support can start with the saved pool, volume and RAID evidence. Request a storage review with exact states, available capacity, recent changes and the recovery copy’s location.
Frequently asked questions
Why is my QNAP pool full when the thick volume has free space?
A thick volume reserves its allocated capacity from the pool in advance. Free space within that volume remains inside the allocation; it is not automatically unallocated capacity in the parent pool.
[2]Will deleting files from a thick volume free pool capacity?
What should I record when a QTS volume reports Read/Delete?
Record the exact volume and parent-pool states, volume type, available pool space, snapshot usage and RAID health. Coordinate affected write workloads and choose the operating-system-specific remedy from that evidence instead of resetting permissions.
Does Threshold Reached mean that my disks have failed?
No. QNAP defines it as pool usage reaching the configured alert threshold. Degraded, Rebuilding and Read-Only states have different meanings and require their own checks.
[1]When can thin-volume space reclaim help?
It can return reclaimable space from a thin volume to the pool, such as after approved unwanted-file deletion. Confirm that a thin volume with reclaimable space exists, then measure the resulting pool availability.
[3]Should I delete all snapshots to restore free space?
Is converting a thick volume to thin harmless?
No. QNAP documents temporary interruption of the volume’s services and permanent deletion of all its snapshots. Treat it as a reviewed storage change with a separately recoverable copy and an agreed change window.
[3]Can a thick volume be shrunk while users keep working?
The QTS 5.2.x resizing guide says the volume is unavailable during shrinking. Confirm the installed release, current state and available action, then plan the interruption rather than assuming it can run transparently.
[4]Does raising the pool warning threshold add capacity?
No. It changes when QTS warns about pool usage. It does not free storage, repair RAID health or increase the physical capacity of the pool.
[5]What proves that a QNAP capacity incident is resolved?
Record adequate pool availability and the expected storage states, then retest disposable file operations with an ordinary account and the actual failed application. Check affected backup and snapshot jobs as well as browsing existing files.
