incorrect error: there is not enough room on the disk to save

[Elias K Gardner]

This is an up to date intrepid amd64 as of 17 oct.

I am trying to download a roughly 150-200mb .wmv file. When I click the link to download firefox asks me if I want to open with movie player or save the file. Before I can answer this another pop up dialog opens with the following message.

"There is not enough room on the disk to save /tmp/dsxlVmgs.wmv.part.
Remove unnecessary files from the disk and try again, or try saving in a different location."

The only option is to click "ok" which then closes both dialogs preventing the file from being saved to "a different location" with more space.

My filesystem (/) and home (/home) are on different partitions. / has 725.1MB free and /home has 11.7GB free as reported by nautilus. Both have enough space for this movie. Oddly /tmp only reports having 992.0KB free.

Here is the relevant output of 'df -h'
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 4.7G 3.8G 726M 85% /
/dev/sda5 74G 59G 12G 84% /home
overflow 1.0M 32K 992K 4% /tmp

First off is /tmp supposed to have a size limit and if so why is mine only 1MB?

The other issue here is that "save file" by default and manual selection saves into the /home partition which has tons of space. Even if my /tmp and / are full it should allow me to save to /home which has space.

SIDE NOTES: I realize my filesystem is too low on space (it only has any free because i ran 'apt-get clean') and I plan to allocate more to it someday when I have access to a cd drive so that i can resize partitions with a live cd.

Could the problem have been that when the computer was turned on it had very very little space causing /tmp to be limited to a very small size and this limit was not changed when more space became available?

[Elias K Gardner (zorkerz)]

Update: after restarting the computer my /tmp file has been resized to have the same amount of free space that my filesystem has.

When downloading the file I observed no activity in /tmp looking through nautilus this means that there is no reason for the second firefox dialogue to prevent the file from being saved to a different location with enough space.

I think this has become two bugs.

1) firefox dialog prevents saving the file to a different location

2) /tmp is not resized automatically when new space is available until the machine is restarted
-its also odd i did not receive a warning from ubuntu I was running out of space
*I have reported the second issue as a new bug 285096

[Dan Trevino (dantrevino)]

 Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[h2g2bob (d-j-batley)]

This is still a bug!

I think the firefox about:config entry to change is browser.cache.disk.parent_directory This requires a restart to firefox, so I'm just going to restart and see if Ubuntu works out that i now have some space on /

[dualbootboy (marduk-eric)]

I'm having the same problem in Ubuntu 9.04. I'm trying to download xampp to my desktop and getting the same error message. Anyone got any ideas?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[markling (markling)]

This effects me on a fresh install of Xubuntu 14.04 LTS. Installed about two weeks ago.

I am suddenly unable to download files. I have been blocked downloading a .pdf and a .zip.

Firefox gives me this error message:

"
There is not enough room on the disc to save /tmp/<filename>

Remove unnecessary files from the disc and try again, or try saving in a different location.
"

Thunar tells me my temp folder has 3.1kb space free. It has two folders in it of 1kb a-piece.

My home directory - where I was attempting to download - has 124Gb free.

I installed using the guided / partition wizard. If the partitions under my bonnet are full up already, it suggests to me a very serious problem with the install.

I had 8Gb in trash. Removed that. Problem unresolved.

Since having my computer on today I've done some browsing, opened a lot of tabs, briefly skimmed/skipped some streaming video, displayed some .pdfs in browser.

I'm using Firefox 29.

here's the output of df:

/dev/mapper/compo--vg-root 321041 262498 37449 88% /
none 4 0 4 0% /sys/fs/cgroup
udev 4 1779980 1% /dev
tmpfs 358844 1036 357808 1% /run
none 5120 0 5120 0% /run/lock
none 1794200 876 1793324 1% /run/shm
none 102400 28 102372 1% /run/user
/dev/mapper/compo--vg-tmp 368615 345060 3 100% /tmp
/dev/sda1 240972 48642 179889 22% /boot
/dev/mapper/compo--vg-home 133915952 5500128 121590252 5% /home
/dev/mapper/compo--vg-usr 8516872 5599420 2461772 70% /usr
/dev/mapper/compo--vg-var 2817056 886128 1768112 34% /var
/home/user/.Private 133915952 5500128 121590252 5% /home/user
/dev/sdb2 447233912 295719692 128772972 70% /media/user/74f8b831-ce17-4911-8787-162f5debcd24

$:/etc# du -chd1 / --exclude={proc,dev,media,mnt,tmp}

5.4G /usr
12K /root
1.0K /opt
1.0K /srv
11G /home
0 /sys
46M /boot
1.0K /lib64
9.5M /bin
12K /lost+found
du: cannot access ‘/run/user/1000/gvfs’: Permission denied
1.9M /run
9.3M /etc
13M /sbin
208M /lib
851M /var
17G /
17G total

[markling (markling)]

Can I suggest the name of this bug is changed?

It seems that the error message is correct. The problem with it is that it is unhelpful.

The bug is not that the message is in error. The bug is that there isn't space to save downloads when there should be. This is a serious bug.

So I would suggest bug name: dowloads blocked by prematurely full tmp

[markling (markling)]

* I reset the machine after clearing trash.
= The .zip file downloaded fine

To try and identify the problem:

* I sent another 8.4Gb of stuff to the trash. (Though this involved deleting some stuff from /home, so it might not have the desired effect).
* Attempted to download another 400Mb zip
= Downloaded a zip without encountering the same problem.

* Copied another 9.5Gb to /home (i.e. does either large transfer have anything to do with this download error?)
* Attempted to download another 400Mb zip
= downloaded fine

* deleted 10Gb from home (i.e. does filling up trash even more recreate the problem?)
= But Thunar sent deleted these files permanently instead of sending them to trash, it didn't give me an option

? So is trash already full up?
= no. df says tmp is 1% full

* Attempted to download another 400Mb zip
= downloaded fine

------

So the problem is with tmp being full. But unable to identify the source of the problem.

[markling (markling)]

Oh, mine is AMD64 as well, btw.

[markling (markling)]

* Sent another 10Gb of files to trash in stages (to get around Xubuntu not wanting to add 10Gb of files to trash all at once < looks like another bug)
* df shows tmp still only 1% full

[markling (markling)]

A related problem that may shed further light on this bug:

Simultabeous to this is a bug that keeps making Thunar crash.

I just tried reporting that bug using ubuntu-bug and got this error:

"""
The problem cannot be reported:

Your home partition has less than 38.345728 MB of free space available, which leads to problems using applications and installing updates. Please free some space.
"""

Yet df shows:

/dev/mapper/compo--vg-home 133915952 10444732 116645648 9% /home

Its full output suggests nothing is full or even near ful:

/dev/mapper/compo--vg-root 321041 262500 37447 88% /
none 4 0 4 0% /sys/fs/cgroup
udev 1779984 4 1779980 1% /dev
tmpfs 358844 1032 357812 1% /run
none 5120 0 5120 0% /run/lock
none 1794200 84 1794116 1% /run/shm
none 102400 36 102364 1% /run/user
/dev/mapper/compo--vg-tmp 368615 2072 342991 1% /tmp
/dev/sda1 240972 48642 179889 22% /boot
/dev/mapper/compo--vg-home 133915952 10444732 116645648 9% /home
/dev/mapper/compo--vg-usr 8516872 5600364 2460828 70% /usr
/dev/mapper/compo--vg-var 2817056 886872 1767368 34% /var
/home/user/.Private 133915952 10444732 116645648 9% /home/user
/dev/sdb2 447233912 298588468 125904196 71% /media/user/74f8b831-ce17-4911-8787-162f5debcd24

Interestingly, another size problem has arisen. This manifested this afternoon, for example, when I copied one large zip file on my local disk over a smaller one of the same name on an external disk (both encrypted separately). After the copy was complete the size was given as a smaller size. It suggested to me the copy had been unsuccessful. But while I was looking at this Thunar crashed. I restarted it and the file was showing the correct, larger size.

Ah but look again at the df output above.

/tmp has just 34Mb space.

So the Thunar error was wrong. It is not that my home directory doesn't have enough space, it is that my tmp doesn't have enough space.

So Elias' orginal report was correct to say the error report was wrong. It is also true that the real problem is that /tmp is getting full and the o/s can't handle it.

It looks like the two are related. The o/s doesn't even know what the problem is to report it properly.

It suggests Xubuntu/Ubuntu guided install procedure for separate partitions is failing to provide paretitions of the correct sizes (this problem has persisted for years). It suggests also that Xubuntu/Ubuntu are unable to work with the partition sizes they opt to give themselves.

(One other event happened in the course of these reports that may or may not have significance for any attempt at diagnosis. That is that I installed KSystemLog using the Ubuntu Software Centre. (This incidentally failed to install an icon on the system menu - this leaves me with no surprise but much despair, but that has become par for the course for this bug-ridden operating system. How about ceasing the annual distr...

[Mikko Rantalainen (mira)]

The workaround for this bug is to set environment variable `TMPDIR` pointing to location that has enough space to temporarily hold the downloaded file.