So today I bother notice an error message being generated by gui program:

(FreeFileSync:21930): dconf-CRITICAL **: 11:46:39.475: unable to create file '/run/user/1000/dconf/user': No space left on device.  dconf will not work properly.

Where /run/user/1000 is a tmpfs for the user's run folder. Thing is that there was plenty of free space on it:

$ df -h /run/user/1000
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           1.6G  120K  1.6G   1% /run/user/1000

So why then? Well then I discover that there are 0 free inodes remaining.

$ df -i /run/user/1000
Filesystem      Inodes   IUsed IFree IUse% Mounted on
tmpfs          2027420 2027420     0  100% /run/user/1000

OK great. However the problems is this: I simply cannot find out the reason for this. Because there are very few files exisiting on this drive, as shown below:

$ echo $PWD ; find . | wc -l

...and other than that, there are very few open programs that are still clinging onto deleted files:

$ sudo lsof $PWD | grep deleted
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
albert    17684   id   72u   REG   0,69     1026  1200359 /run/user/1000/#1200359 (deleted)

Only albert. And after the quitting of albert, the number of used up INodes (100% !) remained the same.

On ubuntu 18.10. My system has been up for quite a long time without a reboot. Still haven't rebooted yet. Will do this soon. And see if that clears the error.


BTW, here is a link to show the difference in output between the du and df commands, in regards to the reported number of used inodes:


They do not seem to agree with each other!


1 Answer 1


You can increase the number of inodes available on a remount. From the kernel documentation :

tmpfs has three mount options for sizing:

size: The limit of allocated bytes for this tmpfs instance. The default is half of your physical RAM without swap. If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory.

nr_blocks: The same as size, but in blocks of PAGE_SIZE.

nr_inodes: The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower.

These parameters accept a suffix k, m or g for kilo, mega and giga and can be changed on remount.

  • 1
    While true, this doesn't explain why the OP has so many used inodes which seems to be the main thrust of the question.
    – terdon
    Jan 3, 2019 at 12:42
  • Rather ironically, looking back to what I wrote yesterday it seems I never actually asked a specific question! But yes: increasing the number of inodes isn't actually going to help very much if they all just get used up again anyhow. And there no actual reason being presented here to justify that if 2027420 is being consumed by only 30 files. Then doubling that number of available inodes will not just consume all the extra new inodes too. Hence then the 'why?', must I really have to ask!!??!!
    – Dreamcat4
    Jan 4, 2019 at 7:26
  • Given the "can't stat" error, have a look at this link
    – JRFerguson
    Jan 4, 2019 at 16:35

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.