Why Doesn’t a NAS Reclaim Space After Deleting Large Files?

A NAS may not regain free space after a large file disappears because deleting its visible name is only one part of storage reclamation. A recycle bin, filesystem snapshot, backup version, or running process can still hold the file’s underlying blocks.

The right fix depends on what still references those blocks. Check the share, snapshot layer, running services, and pool accounting in that order. Do not purge every snapshot or restart the entire NAS before identifying which layer owns the missing space.

The Core Cause: The File Is Gone but Its Blocks Are Still Referenced

A file has a visible directory entry and storage blocks containing its data. Removing the entry makes the file disappear from the folder, but the filesystem can reuse its blocks only after every remaining reference is released. That distinction explains why a successful delete does not always produce an equal increase in free space.

On a Linux-based NAS, a service may keep an already deleted file open. The kernel preserves the data until the final file descriptor closes, even though file browsers and normal directory scans can no longer see it. Red Hat’s explanation of deleted-file space retention shows why stopping or gracefully restarting the holding process releases space that deletion alone did not.

Other holders operate above the open-file layer. A network recycle service may move the file instead of unlinking it, while a copy-on-write snapshot intentionally preserves the older blocks for recovery. The visible result is similar—little or no reclaimed capacity—but the safe corrective action is different.

Which NAS Layer Is Still Holding the Deleted Data?

Start by comparing what changed after deletion. The filename may have moved into a hidden trash directory, the live dataset may have shrunk while snapshot usage increased, or the pool total may remain higher than the files that directory tools can count. Those patterns narrow the holder without destructive cleanup.

A recycle bin is the simplest case. Samba’s VFS recycle-bin behavior intercepts deletion requests and moves files into a repository rather than removing them immediately. A file deleted through an SMB share can therefore remain on the same storage pool even when it has vanished from its original folder.

Snapshots are less obvious because they can preserve blocks without keeping another ordinary file in the live directory. When a snapshot references the pre-deletion state, removing the live file only removes the current reference. This snapshot space-accounting example demonstrates why one snapshot may reclaim little when other snapshots still reference the same blocks.

Pool and share values can also measure different scopes. A share may report its dataset or quota, while the storage dashboard includes child datasets, application data, backup versions, reservations, and snapshot-held blocks. Compare like with like before concluding that the delete failed.

Reclaim Space Without Destroying Recovery History

Reclamation should move from reversible checks to permanent deletion. First refresh the capacity view and confirm that you are reading the correct pool, dataset, and share. A short accounting delay can be normal; a persistent gap after activity settles indicates that another reference or storage scope still needs investigation.

1. Confirm the deleted file is absent from the original share and was not moved or renamed by an application.
2. Inspect the recycle bin associated with that exact share and user account.
3. Review snapshots and backup retention by date, dataset, and estimated reclaimable space.
4. Compare filesystem usage with visible directory totals to identify hidden allocation.
5. Check child datasets, application volumes, quotas, and reservations before changing the pool.
6. Release the confirmed holder through its normal retention, service, or administrative control.

When filesystem usage remains higher than the visible directory total, inspect deleted files that are still open. The lsof open-file check uses lsof +L1 to list files with no remaining directory link. Identify the process and use its normal reload or graceful restart path; do not terminate an unknown database or storage service solely to recover space.

For snapshot-held data, estimate what each retention change will actually reclaim before deleting recovery points. Blocks shared by several snapshots may remain allocated until the last referencing snapshot expires, so removing one snapshot can return much less space than its apparent history size suggests. Preserve recovery value first and adjust retention deliberately.

If routine deletions repeatedly push the pool close to full, the problem is also capacity planning. Recycle retention, snapshots, applications, and backup history need headroom beyond live-file size, so usable NAS capacity planning must include these less-visible consumers.

Frequently Asked Questions

Why did emptying the NAS recycle bin recover only part of the space?

The same blocks may still be referenced by snapshots, backup versions, or an open process. Emptying the recycle bin removes that holder only; it does not override other references or release space reserved by another dataset.

How long should a NAS take to show the newly freed space?

A brief delay while storage accounting and background work settle can be normal. If the value remains unchanged after the dashboard and filesystem statistics are refreshed, check snapshots, deleted-open files, quotas, and whether the displayed number represents the share or the whole pool.

Does RAID prevent deleted files from releasing space?

RAID normally applies the deletion across the active array; it does not preserve the old file as recovery history. Recycle bins and snapshots are separate layers, while RAID protection limits concern availability rather than deleted-file recovery or space retention.