Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am using Linux. And within an uncontrolled event, my 4GB system disk is full.

When I try to uninstall some program by sudo apt-get purge program-name, it gives me this error:

/usr/bin/mandb: can't write to /var/cache/man/25843: No space left on device

Is there any system file that can be deleted in this situation?

share|improve this question
Do you happen to be on a Raspberry pi? I ask because thats the only system I can think of that would have only 4GB. If so, I may have an idea. I'll post if you actually are on a Pi –  evamvid Feb 20 at 22:11
@evamvid This computer is just a tool to do ssh to other computer. This computer is used by several people. When the disk is full, then the users become hectic –  Santosa Sandy Feb 20 at 22:20
@SantosaSandy In that case you should consider using quota. Furthermore it is strange that users can cause this problem as by default a few percent of the file system capacity is reserved for root. –  Hauke Laging Feb 20 at 22:23
@enedil good call, downloaded .deb files are safe to delete. –  Graeme Feb 20 at 23:11
Actually sudo apt-get clean is the command to remove all cached .deb files, not that this matters if you only have 88kB worth. –  Graeme Feb 20 at 23:42

5 Answers 5

You will need to delete some files so that you have a minimum amount of free space again. Which ones to delete will depend on the even that filled up the disk in the first place. Surely some unnecessary files have been created somewhere along the line, your best bet is to find them and delete them!

What can sometimes happen when a program gets out of control is that it can produce excessively large log files with multiple repeated messages. You can check the /var/log directory for this. A good command to use is:

 du -ah /var/log | sort -h

This will sort the largest files at the bottom, so that you can easily see if something has got out of control. The /tmp directory (if it is part of your root filesystem) is another good place to look for problem files.

Another place to look is /var/cache/apt/archives/, this contains the cache of .deb packages downloaded by apt. Files here can be safely removed with apt-get clean.

If you can't find any other files to delete (although perhaps another users home directory is the place to try a du), deleting old log files is probably the safest way to go. Many of the files in /var/log will have numbers after them, the higher the number, the older the log. Many will also have a .gz extension, this is just because they have been compressed to save space.

Other places worth checking are /opt (some non-distro programs use this), /root (the home directory for the root user).

aptitude can be used to purge all configuration files for removed packages. Although typically this will only free a few MBs at best (and won't work if the disk is so full that apt-get won't work). The command line is:

sudo aptitude purge '~c'

Generally I wouldn't recommend uninstalling software unless you really have to, though perhaps the reason for the disk being full is that someone has been installing too much software.

share|improve this answer
Thank you, I will try –  Santosa Sandy Feb 20 at 22:49

Isn't it possible to delete some data? Or log files?

You can create a ramdisk (mount -t tmpfs tmpfs /mnt/tmpfs), move some 100 MiB files there, hope that the system doesn't crash, deinstall some software, and move the files back from the ramdisk.

share|improve this answer
which file I can remove to the '/mnt/tmpfs' –  Santosa Sandy Feb 20 at 22:17
Thanks. Which file I can remove to the '/mnt/tmpfs' ? Can I move /usr/bin ? –  Santosa Sandy Feb 20 at 22:25
@SantosaSandy Data files, home directories of non-logged in users (check their size with du -h before), binaries you do not need during that activity. –  Hauke Laging Feb 20 at 22:25
now I have no other user except root , I had delete all user and also all file in /home/* –  Santosa Sandy Feb 20 at 22:26
@SantosaSandy Sounds crazy. –  Hauke Laging Feb 20 at 22:27

While the other answers here contain good advice, they aren't the most elegant way. As it turns out, ext4 will actually keep 5 MB (IIRC) free for this exact kind of situation.

Reboot your computer. When it starts, choose the recovery mode entry in GRUB (or add recovery to your kernel parameters). When the system boots, you should be able to use APT just fine.

share|improve this answer
Thanks for the advice @strugee . Will the recovery process affect the current ssh process ? Because some user is using it in the meantime. –  Santosa Sandy Feb 21 at 9:37
@SantosaSandy yes, since it requires a reboot. personally, I would announce planned downtime, but it's up to you. –  strugee Feb 21 at 15:30

You can release some disk space by reducing the percentage of reserved blocks for the file system . These reserved blocks are used to avoid file system fragmentation. By default , 5% is reserved. You can reduce it to 2% or 3% to recover some disk space. Setting it to 0% is not recommended as these reserved blocks are used to prevent fragmentation.


  # tune2fs -l /dev/sda9 | grep -i reserve
  Reserved block count:     2691366
  Reserved GDT blocks:      1011
  Reserved blocks uid:      0 (user root)
  Reserved blocks gid:      0 (group root)

  # df -l /dev/sda9
  Filesystem           1K-blocks      Used Available Use% Mounted on
  /dev/sda9            211930464 195169976   5995024  98% /web

  # tune2fs -m 3 /dev/sda9
  tune2fs 1.41.12 (17-May-2010)
  Setting reserved blocks percentage to 3% (1614819 blocks)

After reducing reserved percentage of blocks to 3%, we are able to recover few bytes

  # df -l /dev/sda9
  Filesystem           1K-blocks      Used Available Use% Mounted on
  /dev/sda9            211930464 195169976  10301212  95% /web
share|improve this answer
This is a disk fragmentation alternative. Thank you @Zama Ques, but I am afraid I can not try it right now because there is on going user, which is doing some process meanwhile. –  Santosa Sandy Feb 21 at 11:08
Nice idea. You could also experiment with -O ^resize_inode to free space reserved to enable the filesystem to be grown. This can't be undone though. –  Graeme Feb 23 at 18:24

This is the very not recommended way, but it will give some 100 - 150 MB free space in case of emergency.

I delete the libreoffice,games,gcc,gfortran files in /usr/lib and /usr/share with the intention that I can re-installed it again later.

NB: Analysis of real situation.

This computer is used for providing remote access to another computer. It will have a problem if the user become too much and they make so many remote sessions. The terminal client software also needs some temporary storage. In this case it acquires until 1.4 GB due to some number of sessions conducted by the users. If we just give 4 GB Hard Drive, the situation become dangerous (30% used before considering the file system itself).

Just for more info, each terminal client session saves the cache in /root/.-terminalclient- folder. You can delete some non used session caches that exist here and it will save huge space.

The conclusion is that although the ssh task is simple, we might not allowed to allocate such a small hard drive for this "gateway" computer.

share|improve this answer
uhm... what SSH server are you using? I've never heard of one that needed 1.4 GB worth of temp files –  strugee Feb 21 at 1:09
I am not using putty , but when I examine the folder usage, I found a file /root/.*thesshserversoftwarename*, with the size of that 1.4G –  Santosa Sandy Feb 21 at 9:42
PuTTY is the client. I'm talking about the server. the name of which you have deliberately obscured. –  strugee Feb 21 at 15:32
@strugee I am so sorry so I should revise it to terminal client. My mistake –  Santosa Sandy Feb 21 at 18:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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