An Azure service that provides enterprise-grade file shares powered by NetApp.
Hi Denny Sun,
Thanks for reaching out in Microsoft Q&A forum,
Azure NetApp Files, nfs 950G 898G 53G 95% , file system is 95% full--->but real size is 200GB, WHERE IS ANOTHER 700GB?
NFS volumes on Azure NetApp Files, and usually the “missing space” is not actually lost it’s just not visible via normal directory listing. The gap between what du sees (around 200 GB) and what df reports (around 900 GB) typically boils down to a mix of hidden usage patterns rather than a filesystem bug.
One of the most frequent causes is deleted files that are still open. In Linux/NFS, when a file is deleted but a process keeps it open, the file disappears from the directory tree and is invisible to du, yet it still consumes disk space and shows up in df. This matches your case almost exactly: small visible files but a very large used volume. You can check this with:
-
lsof | grep deleted -
lsof +L1
If you see large entries, identify the PID and restart or kill -9 <PID> to free the space. On web/app servers, this is often long‑running log writers or containers holding deleted log files.
Another common culprit especially on Azure NetApp Files is snapshots. Snapshots are space‑efficient but still consume capacity for changed or retained blocks. Even if your active data is only about 200 GB, snapshots of older versions can easily account for hundreds of GB of “ghost” space that du never sees. You can inspect this:
- In the Azure portal, go to your NetApp volume > Snapshots.
- Or via CLI:
az netappfiles snapshot list ...
Old or unnecessary snapshots can be deleted there, which releases blocks that are no longer referenced.
Sometimes the gap can also come from hidden directories or mount overlays. For example, a new filesystem might be mounted over /shared/ccwebcode/ccwebprod, and old files underneath the mount are hidden but still on the volume. You can sanity‑check this with:
-
df -h -
mount | grep shared -
du -sh /* 2>/dev/null
On NFS mounts, Azure NetApp Files also exposes snapshots via the hidden. snapshot directory. You can look inside it:
-
cd /shared/ccwebcode/ccwebprod/.snapshot -
du -sh *
This lets you see per‑snapshot usage, though reclaiming space still requires deleting snapshots in the portal or CLI.
A final check is comparing apparent size versus actual disk usage. Some apps create large sparse or preallocated files that appear small in size but consume much more space on disk. You can compare:
-
du -h -
du -h --apparent-size
This usually explains only small‑to‑medium gaps, not 700+ GB, so it is less likely in your case.
In practice, with your numbers (200 GB visible vs ~900 GB used), the most likely root causes are:
-deleted‑but‑open files on the Linux/NFS client.
snapshots in Azure NetApp Files retaining older versions of the data as the volume grew.
For more details on how snapshots work and how they affect capacity in Azure NetApp Files, you can refer to the official documentation here: How Azure NetApp Files snapshots work – Microsoft Learn
Kindly let us know if the above helps or you need further assistance on this issue.
do you have email or other cloud disk? I can share more details with you.
You can share details via private messages.
Please do not forget to
and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.