root@rasp:/home/pi# df
df: `/squashfs': No such file or directory
Filesystem     1K-blocks    Used Available Use% Mounted on
rootfs           7498344 7481956         0 100% /
dev               116816       0    116816   0% /dev
/dev/sda1        7498344 7481956         0 100% /mnt
none             7498344 7481956         0 100% /
tmpfs              47560    1360     46200   3% /run
tmpfs               5120       0      5120   0% /run/lock
tmpfs              95100       0     95100   0% /run/shm
/dev/mmcblk0p1   1920672   32128   1888544   2% /media/1235-BBEA

root@rasp:/home/pi#ls|xargs du -s
4       a
5133    bin
20016   boot
19956   boot.bak
384     current.cache
0       dev
3622    etc
11673   home
282159  lib
0       lost+found
32164   media
8       mnt
45560   opt
du: cannot access `proc/23878/task/23878/fd/4': No such file or directory
du: cannot access `proc/23878/task/23878/fdinfo/4': No such file or directory
du: cannot access `proc/23878/fd/4': No such file or directory
du: cannot access `proc/23878/fdinfo/4': No such file or directory
0       proc
110489  root
1360    run
7795    sbin
0       selinux
0       srv
0       sys
80      tmp
1619487 usr
128080  var
12      webmin-setup.out

du -sh
3.6M    .

Had webmin installed and python2.7 and then installed python3.4.
Doing a webmin update failed as it needed 2.7.
Since then disk shows full.Somewhere there is a large
file about 5GB hidden and using all the suggestions in other posts
didn't work.The rpi is 3500 miles away so its a bit hard to work with.
Sounds like I need to go to single user mode and fsck the /dev/sda1
which should happen on a reboot. After spending 3 days on this have run
out of ideas. This probably is more of a Debian/linux question.

  • Try removing everything in /var/cache/apt/archives to free up some space so you can investigate properly. E.g. try for i in a b c d e f g h i j k l m n o p q r s t u v w x y z; do sudo rm /var/cache/apt/archives/$i*; done
    – joan
    Mar 23, 2016 at 14:25
  • Running those du figures up in a spreadsheet and removing the one for /media as it is a separate partition suggests that around 2.3GB is used for the root partition - but that is claiming that 7.4M 1K blocks are used. I must confess I am a little confused but it does look as though something is seriously amiss. And, as it is the super user running the du command you do not have the (default) 5% reserved (for the super-user) space left as headroom to sort things out with. Joan's suggestion to clear out the /var/apt/cache/archive of *.deb files will give you a little space to work in...
    – SlySven
    Mar 23, 2016 at 17:58
  • only 320k in the cache only 125M total in /var
    – M Newton
    Mar 23, 2016 at 21:25

3 Answers 3


I recall coming across a similar situation where a process was holding a file descriptor on a deleted file. Thus, the space could not be freed unless the offending process closed that handle. Try grepping /proc//fd for clues. What is process 23878 doing? Is it perhaps logging to a rotated logfile?

  • That process is probably the initial ls that has terminated by the time the du command gets to consider the output from it - I do not think it is going to be the problem here (if the commands are repeated you would get a similar reports about a different, short-lived process).
    – SlySven
    Mar 23, 2016 at 17:48

You haven't expanded your filesystem. Execute the command shown below when signed into the user 'pi':

sudo raspi-config

When shown with a screen, choose Option 1, to expand your filesystem. Press the enter key when highlighting over the option. This should make you be able to use more space on your Pi.

I don't know what to do about your distance situation but this is what I can suggest for you freeing up space.

  • /dev/mmcblk0p1 is a 2gb sd with bootloader /dev/sda1 is an 8gb usb stick both at max.raspi-config looks for /dev/root and cant find it so wont expand anyway
    – M Newton
    Mar 23, 2016 at 21:16
  • what do you mean grep /proc//fd ?
    – M Newton
    Mar 23, 2016 at 23:57

Fixed it

killed X and apache2

created a forcefsck in /
touch /forcefsck
then forced a reboot

echo b > /proc/sysrq-trigger
this did a reboot and the fsck must have cleaned up the drive. back to normal now

Filesystem     1K-blocks    Used Available Use% Mounted on
rootfs           7498344 2804224   4290180  40% /
dev               116816       0    116816   0% /dev
/dev/sda1        7498344 2804224   4290180  40% /mnt
none             7498344 2804224   4290180  40% /
tmpfs              47560    1220     46340   3% /run
tmpfs               5120       0      5120   0% /run/lock
tmpfs              95100       0     95100   0% /run/shm
/dev/mmcblk0p1   1920672   32128   1888544   2% /media/1235-BBEA


  • In some cases an open file in /tmp may not appear but still uses disk space. If you can find the application that's using it and kill it that usually clears it up - or rebooting. lsof might be help in this case to point to the file in use and what's opening it. Mar 24, 2016 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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