I was running a bash script which created a 14G file in the tmp directory , I deleted it still I cant find the directory or file which is large.

My output for df -h

Filesystem      Size  Used Avail Use% Mounted on
udev            474M     0  474M   0% /dev
tmpfs            99M   11M   88M  11% /run
/dev/vda1        25G   25G     0 100% /
tmpfs           491M     0  491M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           491M     0  491M   0% /sys/fs/cgroup
/dev/vda15      105M  3.9M  101M   4% /boot/efi
/dev/loop0       90M   90M     0 100% /snap/core/7917
/dev/loop1       55M   55M     0 100% /snap/lxd/12211
/dev/loop2       94M   94M     0 100% /snap/core/8935
/dev/loop3       68M   68M     0 100% /snap/lxd/14194
tmpfs            99M     0   99M   0% /run/user/0
/dev/loop4       55M   55M     0 100% /snap/core18/1705
/dev/loop5       49M   49M     0 100% /snap/gtk-common-themes/1474
/dev/loop6      153M  153M     0 100% /snap/chromium/1071
tmpfs            99M     0   99M   0% /run/user/1000

My output for du -sh in / directory

du: cannot access './proc/19935/task/19935/fd/4': No such file or directory
du: cannot access './proc/19935/task/19935/fdinfo/4': No such file or directory
du: cannot access './proc/19935/fd/3': No such file or directory
du: cannot access './proc/19935/fdinfo/3': No such file or directory
4.7G    .

I cant install ncdu or any other tools since the disk is full , considering the summarized size after du -sh where is the rest of the space out of 25GB

My lsb-release


Output for du -sh /*/

119M    /bin/
97M /boot/
0   /dev/
5.9M    /etc/
212M    /home/
682M    /lib/
4.0K    /lib32/
4.0K    /lib64/
4.0K    /libx32/
16K /lost+found/
4.0K    /media/
4.0K    /mnt/
4.0K    /opt/
du: cannot access '/proc/20791/task/20791/fd/4': No such file or directory
du: cannot access '/proc/20791/task/20791/fdinfo/4': No such file or directory
du: cannot access '/proc/20791/fd/3': No such file or directory
du: cannot access '/proc/20791/fdinfo/3': No such file or directory
0   /proc/
72K /root/
11M /run/
30M /sbin/
1.9G    /snap/
4.0K    /srv/
0   /sys/
17M /tmp/
845M    /usr/
768M    /var/
  • Ubuntu 19.04 is EOL or end-of-life (fridge.ubuntu.com/2020/01/23/…) thus off-topic on this site (askubuntu.com/help/on-topic) unless your question is specific to help moving to a supported release of Ubuntu. Use a LTS or long-term-support release if you don't like release-upgrading every 6-9 months. help.ubuntu.com/community/EOLUpgrades (You tagged an EOL release; you'll need to re-install if you don't fix your space issue first, but you can re-install using 'something-else' & no format, it's fast) – guiverc Apr 5 '20 at 9:53
  • it was my mistake , its running 19.10 – Joel Deleep Apr 5 '20 at 9:59
  • did you run du -sh with root permission? – phuclv Apr 5 '20 at 10:04
  • @phuclv yes , i was root while executing the command. I cant find the reason for the difference in du -sh in the / directory and df -h eating all the space – Joel Deleep Apr 5 '20 at 10:05
  • 1
    Does this answer your question? Check how space is distributed on a Linux system – N0rbert Apr 5 '20 at 10:10

The POSIX standard allows you to remove a file while it's still being opened. Only when all processes opening the file has closed then the file is actually deleted

The unlink() function shall remove a link to a file. If path names a symbolic link, unlink() shall remove the symbolic link named by path and shall not affect any file or directory named by the contents of the symbolic link. Otherwise, unlink() shall remove the link named by the pathname pointed to by path and shall decrement the link count of the file referenced by the link.

When the file's link count becomes 0 and no process has the file open, the space occupied by the file shall be freed and the file shall no longer be accessible. If one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file are closed.


So if the running process in the script is still opening the file the space is still consumed and you can't observe it until the process closes the file or is killed

  • no issues now, i was wondering why this is eating up space even though its not showing in the du summary. After the process was complete everything was back to normal. – Joel Deleep Apr 6 '20 at 2:55

How about something like:

du -h -t 500M -a /

-h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G)

-t, --threshold=SIZE exclude entries smaller than SIZE if positive, or entries greater than SIZE if negative

-a, --all write counts for all files, not just directories

  • still no luck, the output seems different when related with the df -h used space – Joel Deleep Apr 5 '20 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.