When using the tab bar, I keep getting this error:

bash: cannot create temp file for here-document: No space left on device"

Any ideas?

I have been doing some research, and many people talk about the /tmp file, which might be having some overflow. When I execute df -h I get:

Filesystem      Size  Used Avail Use% Mounted on 
/dev/sda2       9.1G  8.7G     0 100% /
udev             10M     0   10M   0% /dev
tmpfs           618M  8.8M  609M   2% /run
tmpfs           1.6G     0  1.6G   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.6G     0  1.6G   0% /sys/fs/cgroup
/dev/sda1       511M  132K  511M   1% /boot/efi
/dev/sda4       1.8T  623G  1.1T  37% /home
tmpfs           309M  4.0K  309M   1% /run/user/116
tmpfs           309M     0  309M   0% /run/user/1000

It looks like the /dev/data directory is about to explode, however if I tip:

$ du -sh /dev/sda2
0   /dev/sda2

It seems it's empty.

I am new in Debian and I really don't know how to proceed. I used to typically access this computer via ssh. Besides this problem I have several others with this computer, they might be related, for instance each time I want to enter my user using the GUI (with root it works) I get:

Xsession: warning: unable to write to /tmp: Xsession may exit with an error

  • 2
    You want to run something like du -hxd1 /, not du /dev/sda2. /dev/sda2 doesn't really exist on disk.
    – muru
    Commented Apr 18, 2016 at 22:13

13 Answers 13


If anyone gets here with this error when their disk isn't full, be sure to check not just df but also df -i. There are a fixed number of inodes on a filesystem, and every file needs one. If you have just tons of small files, it's very easy for your filesystem to fill up with these small files while there's still plenty of space left on the drive when you run df.

  • 3
    This was the problem I had! I kept trying to find what was occupying space. That wasn't the problem at all. I had fully used up the inodes. /dev/root 4980000 4980000 0 100% / Maybe the system should respond with an appropriate error message?
    – Capstone
    Commented May 22, 2019 at 6:34
  • Same for me, Plesk server with nginx sometimes crashing and sometimes working, couldn't work out what was wrong until one of our techs got this error on the command line. The number of nodes rather then the space was the issue as identified by df -i. Thanks Commented Apr 9, 2020 at 9:03
  • What am I supposed to do to solve this issue? Commented Apr 26, 2021 at 8:16
  • 2
    @ShahriarRahmanZahin if you have too many files, you'll have to get rid of some. move important stuff elsewhere, delete unneeded old logs or similar. if it's your software, maybe change it to use fewer files ( use an sqlite db instead of filesystem as db perhaps? ), you could use a cron job to purge old unneeded logs and make sure temp files aren't left sitting around. if you control the filesystem, backup and recreate with more inodes available perhaps? I can't give specific answers as I don't know your situation. good luck. Commented Apr 27, 2021 at 14:16
  • 1
    @ShahriarRahmanZahin re: increasing inodes unix.stackexchange.com/questions/26598/… Commented Apr 27, 2021 at 14:17

Your root file system is full and hence your temp dir (/tmp, and /var/tmp for that matter) are also full. A lot of scripts and programs require some space for working files, even lock files. When /tmp is unwriteable bad things happen.

You need to work out how you've filled the filesystem up. Typically places this will happen is in /var/log (check that you're cycling the log files). Or /tmp may be full. There's many, many other ways that a disk can fill up, however.

du -hs /tmp /var/log

You may wish to re-partition to give /tmp it's own partition (that's the old school way of doing it, but if you have plenty of disk it's fine), or map it into memory (which will make it very fast but start to cause swapping issues if you overdo the temporary files).

  • Hi, I looked at both commands that you suggest and I would say that both /tmp and /var/log are quite empty: 60K and 49M respectively. Commented Apr 19, 2016 at 19:18
  • 1
    Hi again. I finally got it. I don't know why did I place all the owncloud content under /var. It works again! Commented Apr 19, 2016 at 19:32
  • 2
    For anyone using ncdu to track down what's taking up space, try running it with sudo. It didn't show me the true size of /var/log until I ran it with sudo because /var/log/httpd was owned by root:root. Commented Jul 2, 2021 at 5:32
  • 1
    the du -hs /tmp /var/log command needs to be executed as super user (sudo) to avoid "Permission denied" errors while reading the aforementioned directories' content
    – KiriSakow
    Commented Jul 23, 2022 at 23:56

You may also have lost write access to the /tmp/ directory.

It should look like that:

ls -l / |grep tmp
drwxrwxrwt   7 root root  4096 Nov  7 17:17 tmp

You can fix the permissions like that:

chmod a+rwxt /tmp
  • This worked for me! Commented Jun 15, 2018 at 5:36
  • 9
    That's a useless use of grep. Try ls -ld /tmp instead.
    – user
    Commented Feb 18, 2019 at 15:18
  • you just halted a near full on panic attack...worth a vote up for me
    – sbeskur
    Commented Nov 15, 2019 at 0:11

The fastest way to locate your folders that are too full is by narrowing down the folder file size in levels from the root folder. You start with the root folder by:

sudo du -h --max-depth=1 /

Then - EITHER you increase the depth, i.e. the levels below:

sudo du -h --max-depth=2 /

OR - quicker - you you look which folder has eaten up the most disk space, and do the same on this folder:

sudo du -h --max-depth=1 /home/<user>/<overfull-folder>

Once you found it, just remove that one:

rm -rf <path to overfull-folder>
  • 4
    with many output files it's nice to sort them by size with sudo du -h --max-depth=1 / | sort -h (bigger files at the bottom or sort -hr for bigger files on top)
    – wranvaud
    Commented Jul 16, 2019 at 21:42
  • This helped me to solve my problem. I was struggling with some hours with this. Commented Jan 5, 2021 at 5:05

I was getting error, then I saw

[  672.995482] EXT4-fs (sda2): Remounting filesystem read-only
[  672.999802] EXT4-fs error (device sda2): ext4_journal_check_start:60: Detected aborted journal

I was able to confirm this,

mount | grep -i sda2
/dev/sda2 on / type ext4 (ro,relatime,errors=remount-ro,data=ordered)
  • dmesg | grep read-only -C 10 Commented Jun 16, 2020 at 16:55

If your using Docker:

Just to help any one using docker, just make sure you are deleting the "left over" images from the building process.

To see which images are currently on disk
$ docker images

It will give you a long list and you can start deleting images that you don't need.

$ docker rmi <image id>.

This should restore your system back to normal.

This is what was causing my problem.


For my case of this same error, it was a cagefs issue as this server was on CloudLinux, addressed with cagefsctl --remount username


I was getting the same error. In my case, the disk was filled up by /var/log/syslog and /var/log/kern.log echoing each other in a blizzard of repeated messages, in what was perhaps a kernel panic. 13 G each file. I couldn't delete or resize in place with sed because I couldn't even sudo or su -. I had to reboot in recovery mode and drop to a root shell to truncate the files, which I did with sed -i '10001,$ d' /var/log/syslog and sed -i '10001,$ d' /var/log/kern.log (the repeating messages started before the 10000th line in both files).


People have written many things here.

But, I simply emptied the trash bin. It works fine for me now.

 rm -rf ~/.local/share/Trash/*
  • 1
    There is no folder in my machine like the one you mentioned : " taccuser@taccuser-All-Series:~/.local/share$ cd Trash -bash: cd: Trash: No such file or directory " Commented Jan 5, 2021 at 4:52

I had this issue on a read-only root filesystem.

I was able to get tab-completion working for the time being by mounting a temporary filesystem in /tmp (sudo mount -t tmpfs tmpfs /tmp), and reopening bash so it could latch onto the new /tmp folder.


Since reboots are very rare on my system , my /tmp had piled up a lot of junk ....Faced this problem recently and cleaned up my /tmp folder.

cd /tmp
sudo rm -rf *
  • Unfortunately this neither contails a check whether /tmp is the problem nor is a good approach. Only older files should be deleted (without a check whether they are in use yet). Commented Jun 25, 2020 at 20:12

Below thing worked for me.

sudo apt-get autoclean

This is because the disk space is not enough, you need to clean up large files or clean up the process that takes up space:

  1. df -h View hard disk space
  2. du -sh /* View which directory is the largest, step by step to find large files
  3. du -h --max-depth=1 find the largest file
  • This seems to just regurgitate the answer by Agile Bean from June 2018.
    – tripleee
    Commented Jun 10, 2019 at 9:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .